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1 

Beschreibung 

Verfahren und Vorrichtungen zum Zugreifen auf Nachrichten 

5 

Die Erfindung betrifft ein Verfahren zum Zugreifen auf 
eine erste Nachricht, insbesondere eine multimediale 
Nachricht vorzugsweise vom MMS-Typ, wobei die erste Nach- 
richt mittels einer Sendeapplikation einer Sendeeinheit 
10 an eine Empf angsapplikation einer Empf angseinheit gesen- 
det wird. 

Des weiteren betrifft die Erfindung eine Sende- und/oder 
Empf angseinheit mit Mitteln zum Erstellen, Versenden, 
15 Empfangen und/oder Verarbeiten einer ersten Nachricht, 
insbesondere einer multimedialen Nachricht vorzugsweise 
vom MMS-Typ . 

Zudem betrifft die Erfindung ein Kommunikationssystem, 
20 insbesondere Funkkommunikationssystem, mit mit Sende- 
und/oder Empf angseinheiten kommunxzierf ahigen Netzwerk- 
elementen, welche Mittel zum Empfangen und Weiterleiten 
von Nachrichten, insbesondere multimedialen Nachrichten 
vorzugsweise vom MMS-Typ, umfassen. 

25 

Das Mobilfunksystem GSM (GSM - Global System for Mobile 
Communications) bietet neben der Sprachtelef onie auch die 
Moglichkeit, kurze Textnachrichten von bis zu 160 Zeichen 
Lange zu versenden bzw. zu empfangen. Dieser Dienst heiSt 
30 SMS (SMS - Short Message Service), s. GSM 03.40 version 
7.4.0, Release 1998; Digital Cellular Telecommunications 
System; Technical Realisation of the Short Message Servi- 
ce (SMS) . 
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Fur das Mobilf unksystem der nachsten Generation UMTS 
-(UMTS - Universal Mobile Telecommunication System) wird 
zur Zeit eine multimediaf ahige Variante eines mobilen 
Nachrichtendienstes standardisiert , der sogenannte MMS 
(MMS - Multimedia Messaging Service) , s. 3G TS 22.140 
version 4.0.1, Release 2000; Third Generation Partnership 
Project; Technical Specification Group Services and Sys- 
tem Aspects; Service Aspects; Stage 1; Multimedia Messa- 
ging Service (MMS) . Nachrichten mit multimedialen Inhal- 
ten werden im folgenden zur besseren Abgrenzung von den 
Textnachrichten des SMS nur noch kurz MMs (MM - Multime- 
dia Message; Plural: MMs) genannt . Im Gegensatz zum SMS 
entfallt die Beschrankung auf reine Textinhalte. Beim MMS 
wird es moglich sein, Texte dem individuellen Geschmack 
entsprechend zu formatieren sowie Audio- und Videoinhalte 
in eine Nachricht einzubetten. Eine weitere Neuigkeit 
ist, dafi bei der Zustellung von MMs bekanntermagen zwi- 
schen dem sogenannten PUSH-Modus (Druck-/Bring-Modus) , 
bei dem eine ankommende MM unverzuglich dem Empfanger zu- 
gestellt wird, und dem sogenannten PULL-Modus (Zieh-/Hol- 
Modus), bei dem der Empfanger zunachst uber eine neu ein- 
getroffene MM informiert wird und daraufhin selbst ent- 
scheiden kann, wann er diese MM auf sein Endgerat herun- 
terladt, unterschieden wird. Diese bekannten Zusammenhan- 
ge sind in Fig. 1 verdeutlicht . 

Nach dem bisherigen Stand der Technik ist eine Implemen- 
tierung von MMS lediglich uber WAP (WAP - Wireless Appli- 
cation Protocol) realisierbar . Zur Uberbriickung der Luft- 
schnittstelle zwischen einem MMS-tauglichen Endgerat und 
dem WAP Gateway ist die Benutzung des WAP WSP (WSP - Wi- 
reless Session Protocol), s. WAP-203 -WSP , Version 4-May- 
2000; Wireless Application Protocol, Wireless Session 
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Protocol Specification; Chapter 8.4: "Header Encoding" , 
vorgesehen, s. 3G TS 22.140 version 4.0.1, Release 2000, 
Third Generation Partnership Project, Technical Specifi- 
cation Group Services and System Aspects, Service 
5 Aspects, Stage 1, Multimedia Messaging Service (MMS) ; 3G 
TS 23.140 version 4.0.0, Release 4, Third Generation 
Partnership Project, Technical Specification Group Termi- 
nals, Multimedia Messaging Service (MMS), Functional 
Description, Stage 2. 

10 

Fig. 2 zeigt ein sogenanntes Transaktions-FluS- 
(Transaction Flow) Diagramm nach heutigem Stand der Tech- 
nik gemaS 3G TS 23.140 version 4.0.0, Release 4, Third 
Generation Partnership Project, Technical Specification 

15 Group Terminals, Multimedia Messaging Service (MMS) , 

Functional Description, Stage 2, in dem der Austausch der 
WAP Nachrichten zwischen den drei beteiligten Instanzen 
(MMS User Agent A, MMS Relay und MMS User Agent B) beim 
Versand und Empfang einer MM dargestellt ist. Unter MMS 

20 User Agent versteht man eine Applikation auf einem Mobil- 
funkgerat oder auf einem an ein Mobilfunkgerat ange- 
schlossenen Gerat (z.B. Laptop, o.a.), die MMS reali- 
siert. Ein MMS Relay ist ein Netzwerkelement im Zustan- 
digkeitsbereich des MMS Service Providers, das den MMS 

25 User Agents die MMS-Funktionalitat zur Verfugung stellt. 

Im folgenden wird anhand des bekannten Transaktions-FluS- 
Diagramms in Fig. 2 („User Agent A schickt MM A an User 
Agent B") der Austausch der WAP Nachrichten beschrieben. 
30 Dabei wird zunachst vereinf achend davon ausgegangen, daS 
MMS User Agent A und MMS User Agent B den MMS vom glei- 
chen MMS Service Provider in Anspruch nehmen: Die im MMS 
User Agent A erzeugte MM A wird mit der WAP Nachricht M- 
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Send.req an das MMS Relay geschickt. Daraufhin erhalt das 
MMS User Agent A die WAP Nachricht M-Send.conf zuruck,. 
mit der der korrekte Empfang der MM A vom MMS Relay bestS- 
tigt wird. In ihr ist auch eine vom MMS Relay festgeleg- 
te, moglicherweise individuelle , Identif ikationsnummer 
ID1 fur die abgeschickte MM A enthalten. Danach informiert 
das MMS Relay das MMS User Agent B mit der WAP Nachricht 
M-Notification. ind iiber den Speicherplatz (URI - Uniform 
Resource Identifier) der neu eingetrof f enen und zum Her- 
unterladen (Download) bereitliegenden MM A . Das MMS Relay 
erhalt daraufhin z.B. mit der WAP Nachricht M- 
NotifyResp.req eine Bestatigung, daS die Benachrichtigung 
iiber die eingetrof fene MM A (M-Notification . ind) erfolg- 
reich zugestellt worden ist. Zu diesem Zeitpunkt hat das 
MMS Relay noch keine Nachrichten-ID fur die zum Herunter- 
laden bereitliegende MM vergeben. Beim Austausch der bei- 
den WAP Nachrichten M-Notification. ind und M- 
NotifyResp.req wird nur eine fur diese Benachrichtigung 
individuelle Transaktions-Identitatsnummer {Transaction- 
ID) ausgetauscht . Das MMS User Agent B fordert dann mit 
Hilfe der WAP Nachricht WSP GET, mit der der URI an das 
MMS Relay geschickt wird, die Auslieferung der MM A an. 
Mit der WAP Nachricht M-Retrieve . conf wird dem MMS User 
Agent B daraufhin vom MMS Relay die gewiinschte MM A zuge- 
stellt. Hierbei wird die MM A iiber die vom MMS Relay ver- 
gebene, moglicherweise individuelle, Identif ikationsnum- 
mer ID2 identif iziert. Mit der WAP Nachricht M- 
Acknowledge.ind wird der korrekte Empfang der MM A vom MMS 
User Agent B quittiert. Fur den Fall, da£ der Absender 
den Wunsch geauSert hat, iiber einen erf olgreichen Empfang 
der von ihm verschickten MM A benachrichtigt zu werden, 
kann das MMS Relay dem nachkommen, indem die WAP Nach- 
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richt M-Delivery. ind an das MMS User Agent A geschickt 
wird. 

Fig. 3 zeigt eine bekannte mogliche MMS Architektur, bei 
5 der die beiden am Austausch einer MM beteiligten MMS User 
Agents (MMS User Agent A mit Bezugszeichen 1 und MMS User 
Agent B mit Bezugszeichen 11) den MMS von verschiedenen 
MMS Service Providern (MMS Service Provider A und MMS 
Service Provider B) in Anspruch nehmen. In diesem Fall 

10 ist eine Weiterleitung der MM zwischen den MMSEs (MMSE - 
Multimedia Messaging Service Environment) der beteiligten 
MMS Service Provider notig. Das Bezugszeichen 4 kenn- 
zeichnet die MMSE des Service Providers A und das Bezugs- 
zeichen 14 die MMSE des Service Providers B. Die Weiter- 

15 leitung einer MM zwischen zwei MMSEs und hierbei genauer 
zwischen der Sendeapplikation MMS Relay A mit Bezugszei- 
chen 2 und der Empf angsapplikation MMS Relay B mit Be- 
zugszeichen 12) geschieht uber SMTP (SMTP - Simple Mail 
Transfer Protocol), s. 3G TS 23.140 version 4.0.0, Re- 

20 lease 4, Third Generation Partnership Project, Technical 
Specification Group Terminals, Multimedia Messaging Ser- 
vice (MMS) Functional Description, Stage 2, z.B. durch 
das Internet (IP - Internet Protocol mit Bezugszeichen 
20). Das Protokoll SMTP ist in Fig. 3 mit dem Bezugszei- 

25 chen 22 bezeichnet. Das Mobilf unknetz wird in Fig. 3 wie 
allgemein ublich als PLMN (PLMN - Public Land Mobile Net- 
work) bezeichnet und tragt in Fig. 3 das Bezugszeichen 6. 
Jeder MM kann beim Editieren ein Zeitpunkt zugewiesen 
werden, zu dem die MM fruhestens dem Empf anger, dem MMS 

30 User Agent B mit Bezugszeichen 11, zugestellt werden 

soil. Wird davon Gebrauch gemacht, ist eine Zwischenspei- 
cherung der MM im MMSE A 4 (genauer: einem Speicher MMS 
Server A mit Bezugszeichen 3) des Absenders (MMS User A- 
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gent A) 1 bis zum Erreichen dieser Frist vorgesehen, s. 
Report of the 3 GPP TSG-T2 SWG3 MMS Ad Hoc Meeting #5 in 
Sophia Antipolis, France 10-12 October 2000; T-doc : 
T2M00092; chapter 7; 3GPP TSG-T2 SWG3 . Erst danach wird 
die MM an das MMSE B 14 des EmpfSngers (MMS User Agent B) 
11 iibermittelt. Weiterhin kann beim Editieren einer jeden 
MM auch eine gewunschte Giiltigkeitsdauer angegeben wer- 
den. Die Speicherung einer MM bis zum Ablauf der Giiltig- 
keit bzw. bis zum vorherigen Download der MM durch den 
MMS User Agent B 11 soil im MMSE B 14 (genauer: in einem 
Speicher MMS Server B mit Bezugszeichen 13) des Empf an- 
gers 11 stattfinden, s. Report of the 3GPP TSG-T2 SWG3 
MMS Ad Hoc Meeting #5 in Sophia Antipolis, France 10-12 
October 2000; T-doc : T2M00092; chapter 7; 3GPP TSG-T2 
SWG3. 



Bei den eingangs genannten Verfahren und Vorrichtungen 
ist eine Nachricht vom Absender bzw. Auftraggeber bear- 
beitbar, solange sie sich noch in der Sendeapplikation 
MMS User Agent A befindet. Wenn die Nachricht abgesandt 
wurde, besteht keine Moglichkeit der Beeinf lussung bzw. 
des Zugreifens mehr. Dieses Problem besteht nicht nur bei 
der Versendung von Nachrichten iiber Funk, sondern auch 
bei der Versendung von elektronischer Post (Emails) iiber 
das Internet und anderen Nachrichten-Systemen . 

Es ist Aufgabe der vorliegenden Erfindung, das Verfahren 
und die Vorrichtungen der eingangs genannten Art derart 
weiterzubilden, daS eine mehr den Bedurfnissen des Absen- 
der s/ Empf angers orientiertere Bearbeitung bzw. Beeinf lus- 
sung von Nachrichten ermoglicht wird. 
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Diese Aufgabe wird bei dem Verfahren der eingangs genann- 
ten Art dadurch gelost, daS eine zweite Nachricht mit ei- 
nem Manipulationsauf trag zur Manipulation der ersten 
Nachricht erstellt, versendet, empfangen, wei tergeleitet 
5 und/oder verarbeitet wird, urn einen manipulierenden 

Zugriff auf die erste Nachricht zu veranlassen oder zu 
vermitteln. 

Weiterhin wird diese Aufgabe bei einer Sende- und/oder 
10 Empfangseinheit der eingangs genannten Art gelost Mittel 
zum Erstellen, Versenden, Empfangen und/oder Verarbeiten 
einer zweiten Nachricht, wobei die zweite Nachricht einen 
Manipulationsauf trag zum Manipulieren einer zuvor gesen- 
deten ersten Nachricht umf aSt . Unter dem Begriff Sende- 
15 und/oder Empfangseinheit werden insbesondere Mobilfunkte- 
lefone sowie mit dem Internet verbundene Kommunikations- 
einheiten einschliefelich Computer verstanden. Die erfin- 
dungsgemaSen Mittel zum Erstellen, Versenden, Empfangen 
und/oder Verarbeiten der zweiten Nachricht umfassen - ne- 
20 ben den geratetechnischen Voraussetzungen - insbesondere 
Softwarelosungen, die nachfolgend genauer vorgestellt 
werden und bevorzugt Modif ikationen von WAP-Nachrichten 
mit veranderten und/oder neu definierten Kopffeldern dar- 
stellen bzw. diese verarbeiten konnen. 

25 

Zudem wird diese Aufgabe bei einem Kommunikat ions system 
der eingangs genannten Art dadurch gelost, daS mindestens 
eines der Netzwerkelemente Mittel zum Empfangen, Verar- 
beiten und/oder Weiterleiten einer zweiten Nachricht mit 
30 einem Manipulationsauf trag umfaSt, welcher sich auf eine 
empfangene und ggf . schon weitergeleitete erste Nachricht 
bezieht, urn einen manipulierenden Zugriff auf die erste 
Nachricht zu veranlassen oder zu vermitteln. Im Sinne 
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dieser Erfindung wird unter einem Kommunikationssystem 
ein System mit Netzwerkelementen verstanden, die eine 
Kommunikation zwischen mehreren Sende- und/oder Empfangs- 
einheiten, insbesondere mehreren Mobiltelef onen und/oder 
ans Internet angeschlossenen Rechnem, ermoglichen. Das 
Kommunikationssystem einschliefilich Funkkommunikations- 
systeme wird ublicherweise von Service Providern betrie- 
ben. Die erf indungsgemaSen Mittel zum Empfangen, Verar- 
beiten und/oder Weiterleiten der zweiten Nachricht 
schlieSen aufien den notwendigen Hardware-Elementen insbe- 
sondere Sofware ein, die im folgenden genauer beschrieben 
wird und bevorzugt Modif ikationen von WAP-Nachrichten mit 
ensprechend angepaSten oder neu definierten Kopffeldern 
darstellen bzw. diese verarbeiten konnen. 

Eine Nachricht im Sinne dieser Erfindung kann sowohl eine 
herkommliche SMS, eine MM mit multimedialen Inhalten oder 
eine sonstige elektronische Nachricht sein. Im folgenden 
wird die Erfindung anhand der MM beschrieben, ohne dag 
hierdurch eine Einschrankung auf diesen Nachrichtentyp 
erfolgen soli. Fur die erste Nachricht wird im folgenden 
die Abklirzung MM A/ fur die zweite Nachricht die Abkiirzung 
MM B verwendet . 

Die Vorteile der Erfindung liegen insbesondere darin, dag 
es ermoglicht wird, eine erste Nachricht nach dem Abschi- 
cken zu manipulieren, insbesondere zuruckzuruf en -und/oder 
nachtraglich eine Veranderung bzw. Aktualisierung an ihr 
vorzunehmen. Eine solche Manipulation kann gemafi der Er- 
findung bei der Versendung von Nachrichten uber Funk, li- 
ber Mobilfunksysteme, zwischen Mobilfunksystemen, insbe- 
sondere liber ein Inter-Operator-IP-backbone, zwischen Mo- 
bilfunknetzen und anderen Nachrichten-Systemen, insbeson- 
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dere Internet-Email, und/oder liber das Internet moglich 
sein . 

Insbesondere ist es mit Hilfe der vorliegenden Erfindung 
moglich, eine von einem Auftraggeber mittels einer Sende- 
applikation einer Sendeeinheit tiber mindestens ein Netz- 
werkelement an eine Empf angsapplikation einer Empfangs- 
einheit gesendete erste Nachricht - insbesondere eine 
Multimedia Message nach dem MMS-Typ - zu manipulieren, 
wobei nach Versenden der ersten Nachricht eine zweite 
Nachricht mit einer Manipulierinf ormation von der Sende- 
einheit an mindestens ein Netzwerkelement ubermittelt 
wird, das einen manipulierenden Zugriff auf die erste 
Nachricht veranlaSt oder vermittelt. 

Die erste Nachricht und die zweite Nachricht werden • iiber 
mindestens ein senderseitiges Netzwerkelement eines Ser- 
vice Providers und mindestens ein empf angerseitiges Netz- 
werkelement eines Service Providers an die Empf angsappli- 
kation gesendet . Hierbei konnen das mindestens eine sen- 
derseitige Netzwerkelement und das mindestens eine emp- 
fangerseitige Netzwerkelement dem Zustandigkei tsbereich 
eines einzigen Service Providers angehoren oder sogar - 
im einfachsten Fall - identisch sind. 

Auch sind Falle einer Identitat der Empfangs- und der 
Sendeapplikation moglich. 

Besonders bevorzugt erfolgt der manipulierende Zugriff 
auf die erste Nachricht auf einem sendersei tigen Netz- 
werkelement, auf einem empf angersei tigen Netzwerkelement 
und/oder auf der Empf angsapplikation . 
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1st die Empfangsapplikation noch nicht uber den Manipula- 
tionsauf trag informiert worden, wird die erste Nachricht 
bevorzugt entweder im Zustandigkeitsbereich des sender- 
seitigen oder des empf angerseitigen Service Providers ma- 
nipuliert, vorzugsweise ohne die Empfangsapplikation tiber 
die Manipulation zu benachrichtigen . 1st die Benachrich- 
tigung uber die erste Nachricht schon an die Empfangssei- 
te hingegen erfolgt, aber ist diese erste Nachricht noch 
nicht heruntergeladen, wird vorzugsweise die erste Nach- 
richt im Zustandigkeitsbereich des senderseitigen Service 
•Providers ohne Informieren der Empfangsapplikation mani- 
puliert, oder die Manipulation erfolgt im Zustandigkeits- 
bereich des empf angerseitigen Service Providers, wobei 
bevorzugt die Empfangsapplikation uber die Manipulation 
und deren Zeitpunkt informiert wird. 

Die erf indungsgemaSe Manipulation ist nicht auf die bei- 
den Dienstmerkmale Zuruckrufen und Andern beschrankt. 
Auch Auftrage zu einer nachtraglichen Weiterleitung (For- 
warding) , ein nachtragliches Anhangen der zweiten Nach- 
richt an die erste Nachricht, usw. wird im Sinne dieser 
Erfindung unter einer Manipulation verstanden. Im folgen- 
den werden der Ruckruf- und der Anderungs -Auf trag genauer 
beschrieben. 

GemaS der Erfindung kann das Zuruckrufen (im Rahmen die- 
ser Offenbarung mit „Recall" bezeichnet) einer MM zumin- 
dest immer noch solange moglich sein, bis sie der Empf an- 
ger in einen anderen Ordner verschoben, an einen anderen 
Empf anger weitergeleitet oder geoffnet hat. 

Das nachtragliche Andern (im Rahmen dieser Offenbarung 
mit „Replace" bezeichnet) einer MM hingegen ist vorteil- 
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hafterweise auch dann noch moglich, wenn der Empfanger 
die MM schon „angefaSt" hat. In diesem Fall wird der Emp- 
fanger vorzugsweise umgehend iiber eine nachtragliche An- 
derung der entsprechenden MM informiert, entweder durch 
eine Benachrichtigung (Notification) , damit er den Down- 
load der aktualisierten MM nachtraglich selbst einleiten 
kann (Pull-Modus) , oder gleich durch eine automat ische 
Zustellung der aktualisierten MM (Push-Modus) . 

Des weiteren ist Gegenstand der Erfindung die Implemen- 
tierung des erf indungsgemafien Verfahrens in WAP durch die 
Modifikation von vorhandenen Header-Feldern oder das Hin- 
zufugen von neu definierten Header-Feldern in die betrof- 
fenen WAP Nachrichten des WAP-MMSEncapsulation Standards, 
s. WAP-2 09-MMSEncapsulation, Release 2000; Wireless Ap- 
plication Protocol; WAP Multimedia Messaging Service; 
Message Encapsulation; MMS Proposed SCD 1.0. 

Ebenso ist das entsprechende binare Encoding, wie weiter 
unten fur ein Ausf uhrungsbeispiel beschrieben, Gegenstand 
der vorliegenden Erfindung. 

Im folgenden wird die Erfindung anhand von Beispielen na- 
her erlautert . 

Es zeigen: 

Fig. 1 eine Gegeniiberstellung des PULL- und PUSH-Modus 
gemaS UMTS nach dem Stand der Technik; 

Fig. 2 ein Multimedia Messaging Service (MMS) Transak- 
tions-Diagramm nach dem Stand der Technik; 
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Fig. 3 eine schematische Darstellung einer Multimedia 
- - - Messaging Architektur nach dem Stand der Tech- 
nik; 

Fig. 4 ein Multimedia Messaging Service (MMS) mit ei- 
ner Manipulationsmoglichkeit einer ersten Nach- 
richt gemaS der vorliegenden Erfindung; 

Fig. 5 eine Codierung von neu definierten Kopffeldern 
(Header-Felder) ; 



Fig. 6 Erganzungen im bekannten Kopffeld X-Mms- Status; 

Fig. 7 neu eingefuhrtes Kopffeld X-Mms -Original - 
Message-Status; und 

Fig. 8 neu eingefuhrtes Kopffeld X-Mms -Original - 
Message-ID. 



Es wird - unter Bezugnahme auf das obere Drittel der Fig. 
4 - bei der Beschreibung der Ausfiihrungsbeispiele von dem 
folgenden, bekannten Ablauf des Versendens und Empfangens 
einer ersten Nachricht MM A durch Vermittlung eines ersten 
und eines zweiten Service Providers (Service Provider A 
und Service Provider B) ausgegangen: Nach dem Verschicken 
der ersten Nachricht MM A wird der Sendeapplikation MMS 
User Agent A des Absenders in der WAP Nachricht M- 
send.conf eine Message-ID fur die zuvor verschickte MM A 
mitgeteilt (ID1) . Diese Identif ikationsnummer ID1 wird 
vom Netzwerkelement MMS Relay A des Service Providers A 
erzeugt und kennzeichnet die MM A innerhalb der sendersei- 
tigen Schnittstelle MMS User Agent A / MMS Relay A ein- 
deutig. Bei der empf angerseitigen Zustellung der MM A vom 
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Netzwerkelement MMS Relay B des Service Providers B zur 
Empf angsapplikation MMS User Agent B durch die WAP Nach- 
richt M-Retrieve. conf wird ebenfalls eine Message-ID (ID2 
in Fig. 2) ubermittelt. Diese Identif ikationsnummer ID2 
5 wird moglicherweise vom MMS Relay B neu erzeugt und dient 
zur eindeutigen empf angerseitigen Kennzeichnung der MM A 
innerhalb der Schnittstelle MMS Relay B / MMS User Agent 
B. 

10 Zur Ubermittlung der MM A zwischen dem senderseitigen MMS 
Relay A und dem empf angerseitigen MMS Relay B kann ID1 in 
eine Interim- Identif ikationsnummer (ID3) umgewandelt wer- 
den, welche die MM A zwischen den verschiedenen Systemen 
identif iziert . Insbesondere sollte ID3 global eindeutig 

15 sein. Z.B. enthalt ID3 Inf ormationen hinsichtlich des 

Service Providers A, der ID1 sowie dem Zeitpunkt der ID- 
Umwandlung. Dazu muS das senderseitige MMS Relay A die 
Information bzw. die Moglichkeit besitzen,. diese Umwand- 
lung wieder ruckgangig zu machen, z.B fur Auslief erungs- 

20 berichte. Um intern iibersichtliche IDs zu benutzen, kann 
ID3 vom empf angerseitigen MMS Relay B in die oben erwahn- 
te interne ID2 umgewandelt werden, welche die MM A zum 
Empf anger MMS User Agent B identif iziert . Dazu muS wie- 
derum das empf angerseitige MMS Relay B die Information 

25 bzw. die Moglichkeit besitzen, diese Umwandlung wieder 

ruckgangig zu machen, z.B. fur Auslief erungsberichte . Die 
MM A wird empf angerseitig durch ID2 identif iziert . 

GemaS der Erfindung wird nun von der Sendeapplikation, 
30 der Empf angsapplikation und/oder zwischen der Sende- und 
Empf angsapplikation vermittelnden Netzwerkelementen die 
Moglichkeit zum Zugriff auf die zuvor versendete erste 
Nachricht MM A berei tgestellt , indem eine zweite Nachricht 
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MM B bereitgestellt wird, die einen manipulierenden 
Zugriff auf die erste Nachricht MM A veranlaSt oder ver- 
mittelt . 

Eine Moglichkeit der Identif ikation von MM B wird folgend 
anhand der Fig. 4 erlautert, bei der MM B die Identifika- 
tionsnummer ID4 tragt. Zur Ubermittlung von MM B zwischen 
den verschiedenen Service Providern Systemen kann ID4 vom 
senderseitigen MMS Relay A umgewandelt werden in eine In- 
terim-ID (ID6) # welche MM B zwischen den Systemen identi- 
f iziert. Insbesondere sollte ID6 global eindeutig sein, 
z.B. eine Kombination von Inf ormationen hinsichtlich des 
Service Providers A, ID4 und Zeitpunkt der Umwandlung 
enthalten. Dazu mug das senderseitige MMS Relay A die In- 
formation bzw. die Moglichkeit besitzen, diese Umwandlung 
wieder ruckgangig zu machen, z.B. fur Auslief erungsbe- 
richte. Urn intern ubersichtlichere IDs zu benutzen, kann 
ID6 vom empfangerseitigen MMS Relay B umgewandelt werden 
in eine interne ID (ID5), welche MM B zum Empf anger MMS 
User Agent B identif iziert . Dazu mufi das empf angerseitige 
MMS Relay B die Information bzw. die Moglichkeit besit- 
zen, diese Umwandlung wieder ruckgangig zu machen, z.B. 
fur Auslief erungsberichte . MM B wird empf angerseitig durch 
IDS identif iziert . 

Urn die notwendige Verbindung. von MM A und MM B zu realisie- 
ren, weist ID4 eine Referenz zu ID1, ID6 eine Referenz zu 
ID3 und ID5 eine Referenz zu ID2 auf. Die Benachrichti- 
gungen der Empf angsapplikation MMS User Agent B liber MM A 
und MM B verweisen zudem auf zwei Speicherplatze URI1 bzw. 
URI2 . 

Es ist moglich, daS die Identif ikationsnummern ID1 und 
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ID3, ID3 und ID2 , sowie ID1, ID2 und ID3 identisch sind. 
Ebenso konnen ID4 und ID6, ID6 und IDS, sowie ID4, IDS 
und ID6 identisch sein. 

Zumindest eines der beteiligten senderseitigen und eines 
der beteiligten empf angerseitigen Netzwerkelmenente ist 
vorteilhaf terweise in der Lage, eine eineindeutige, um- 
kehrbare Umwandlung von IDs vorzunehmen und die Informa- 
tionen hieriiber zu verwalten. 

Im folgenden werden die Manipulationsmoglichkeiten „Ruck- 
ruf" und „Andern u beispielhaft beschrieben, worunter un- 
ter dem letzteren Begriff im Sinne dieser Erfindung bei- 
spielsweise eine Aktualisierung der ersten Nachricht MM A 
verstanden wird, insbesondere durch Ersetzen der ersten 
Nachricht durch die zweite Nachricht. Allgemein sind je- 
doch alle Kombinationen der gemafi dieser Erfindung offen- 
barten Optionen fur alle Arten von Manipulationen reali- 
sierbar, so z.B. ob und mit welchen Inf ormationen der 
Empfanger liber eine Manipulation einer ersten Nachricht 
benachrichtigt wird, ob uber die Art der Manipulation in- 
formiert werden soil, ob der Empfanger uber einen Manipu- 
lationswunsch des Absenders informiert werden soil, ob 
die zweite Nachricht im PULL- oder im PUSH-Modus zuge- 
stellt werden soil, ob die Anderung auf einem sendersei- 
tigen oder empf angerseitigen Netzwerkelement oder auf der 
Empf angsapplikation MMS User Agent B erfolgen soil, ob 
der Absender und/oder der Empfanger uber den Erfolg der 
Manipulation benachrichtigt werden soli, usw. 

A • Riickruf -Diens tmerkmal 



GemaS der Erfindung kann ein Benutzer des MMS, der eine 
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erste Multimedia Message MM A abgeschickt hat und diese 
bereits vers chi ckte ~MM A wieder zuriickru fen mochte, eine 
neue, zweite Nachricht MM B mit der Information verschi- 
cken, da£ die zuvor verschickte, erste Nachricht MM A wie- 
der zurtickgeruf en werden soil. 

Dies kann erf indungsgemaS bevorzugt dadurch realisiert 
werden, indem der Absender die neue MM B verfafit, die ei- 
nen Ruckruf -Befehl , aber bevorzugt keinen fur den Empf an- 
ger bestimmten Inhalt (Content /Message Body) , beinhaltet, 
und diese an den gleichen Empfanger wie die zuvor ver- 
schickte MM A schickt. Als Ruckruf -Kennung wird bevorzugt 
die ID1 der zuvor verschickten MM A benutzt. Die MM B mit 
der Ruckruf -Information gelangt zunachst zum MMS Relay A 
des Absenders. Hier wird zweckmaSigerweise iiberpruft, ob 
die MM A mit der ID1 noch im Zustandigkeitsbereich des 
Service Providers A (MMSE A ) ist, oder ob sie schon an das 
MMSEb des Service Providers B weitergeleitet worden ist. 
Ersteres ist z.B. der Fall, wenn der vom Absender gewahl- 
te Zeitpunkt fur die gewunschte Zustellung seiner MM A 
noch nicht erreicht worden ist; letzteres ist z.B. der 
Fall, wenn die MM A noch nicht ihre Giiltigkeitsdauer iiber- 
schritten hat und noch nicht dem MMS User Agent B zuge- 
stellt worden ist. Sobald die MM A in einem MMSE der be- 
teiligten MMS Service Provider ausfindig gemacht wird, 
kann das Loschen von MM A und MM B vom zustandigen MMS Re- 
lay eingeleitet werden. 

Falls das MMS User Agent B schon uber die fur ihn- im 
MMSEb bereitliegenden MM A mittels einer Benachrichtigung 
(Notification) informiert worden ist und sich die MM A 
noch im Zustandigkeitsbereich/ Speicher des Service Provi- 
ders B befinden sollte, kann nach dieser Erfindung das 



200100797 



17 

MMS User Agent B mit einer erneuten Benachrichtigung (No- 
tification) davon in Kenntnis gesetzt werden, daS die MM A 
vom Service Provider B geloscht worden ist und somit 
nicht mehr zum Download bereit liegt, weil der Absender 
sie zuriickgeruf en hat. AuSerdem hat der MMS Service Pro- 
vider B nach dieser Erfindung die Moglichkeit, dem MMS 
User Agent B das Datum der Ausfuhrung des Ruckruf -Befehls 
zu ubermitteln. 

Sollte die MM A schon an den Empfanger ausgeliefert worden 
sein, so kann das MMS User Agent B des Empf angers mit der 
o.g. erneuten Benachrichtigung (Notification) davon in 
Kenntnis gesetzt werden, daS der Absender die MM A zuruck- 
rufen mochte. Das Loschen der MM A kann nach dieser Erfin- 
dung direkt im MMS User Agent B stattfinden, sofern die- 
ses das Ruckruf -Dienstmerkmal unterstutzt. Je nach Imple- 
mentierung dieses Dienstmerkmals im Endgerat, den Ein- 
stellungen des Benutzers, den Einstellungen des MMS Ser- 
vice Providers und/oder des Netzbetreibers kann das Lo- 
schen der MM A im Endgerat davon abhangig sein, ob die MM A 
bereits vom Empfanger „angefaSt" (z.B. geoffnet, gelesen, 
weitergeleitet , etc.) worden ist. Sinnvoll erscheint je- 
doch, nur solche MMs nach der Auslieferung zu loschen, 
welche noch nicht vom Empfanger „angefa£t xx worden sind. 
Die MM B mit der Ruckruf -Information muS dem MMS User A- 
gent B nicht unbedingt zugestellt werden; sie kann schon 
im MMSE B geloscht werden. 

Hat der Empfanger (MMS User Agent B) der MM A noch keine 
Benachrichtigung uber die MM A erhalten, etwa weil die MM B 
mit der Ruckruf -Information das MMS Relay B vor der ruck- 
zurufenden MM A erreicht, mug dieser auch nicht uber eine 
vom Absender eingeleitete Ruckruf -Aktion informiert wer- 



200100797 

18 

den. Statt dessen wartet das MMS Relay B vorzugsweise, 
bis es die zum Riickruf ref erenzierte MM A erhalt und 
loscht diese beim Eintreffen, ohne den Empfanger zu be- 
nachrichtigen ( vorausgesetzt , das MMS Relay B unterstutzt 
das Ruckruf-Dienstmerkmal) . Alternativ kann die Loschung 
von MM A auch schon auf dem MMS Relay A erfolgen. 

Der Auftraggeber des Ruckrufs (MMS User Agent A) wird ge- 
maS der vorliegenden Erfindung uber den Ausgang und das 
Datum der Ausfuhrung der von ihm eingeleiteten Aktion 
vorzugsweise informiert, wenn die beteiligten MMS Service 
Provider dies ermoglichen. 

Urn das gerade beschriebene Di ens truer kmal Riickruf umsetzen 
zu konnen, schlagt die vorliegende Erfindung vor, daS ei- 
ne oder mehrere der folgenden Inf ormationen zusatzlich 
zwischen den beteiligten Instanzen (MMS User Agent A, MMS 
Relay A, MMS Relay B und MMS User Agent B) ausgetauscht 
werden : 

MMS User Agent A MMS Relay A (beim Versenden einer 
MM) : 

• Kennzeichnung, daS es sich bei einer MM B urn einen 
Riickruf -Befehl handelt. 

• I dent if ikationsnummer der MM A ,- die zuriickgeruf en wer- 
den soil. 

• Information, daS der Absender eine Ruckmeldung uber 
den Ausgang der von ihm initiierten Riickruf -Aktion an- 
f ordert . 



MMS Relay A -> MMS User Agent A (bei der Bestatigung nach 
dem Versendens einer MM) : 
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• Mitteilung des Service Providers , ob dieser das Ruck- 
ruf -Dienstmerkmal unterstutzt . 

MMS Relay A — » MMS Relay B (nur dann notig, wenn Absender 
und Empfanger zu unterschiedlichen MMSEs gehoren) : 

• Kennzeichnung, daS es sich bei einer MM B urn einen 
Ruckruf -Befehl handelt. 

• Identif ikationsnummer der MM A , die zurtickgeruf en wer- 
den soil. 

• Information, dafi der Absender eine Ruckmeldung liber 
den Ausgang der von ihm initiierten Ruckruf -Aktion an- 
f ordert . 

Die Ubermittlung der Informationen zwischen MMS Relay A 
und MMS Relay B ist davon abhangig, ob diese Informatio- 
nen beim Versenden der MM B vorhanden waren. 

MMS Relay B MMS User Agent B (bei der Benachrichtigung 
iiber eine eingetrof f ene MM) , vorzugsweise in einer Nach- 
richt : 

• Information, wann der Ruckruf ausgefuhrt wurde. 

• Information, daS eine zuvor durch eine Benachrichti- 
gung angekundigte MM A nun nicht mehr zum Download be- 
reitliegt. Identif izierung der MM A , die im MMSE B ge- 
loscht worden ist, erfolgt anhand der Nachrichtenref e- 
renz (Message Reference; URI) . 

Oder : 

• Information, daS eine bereits ausgelief erte MM A vom 
Absender zurtickgeruf en wird. Identif izierung der MM A , 
die zuruckgeruf en wird, erfolgt auf dem MMS User Agent 
B anhand der Nachrichten-ID 



200100797 

20 

• MMS User Agent B — » MMS Relay B (nach der Benachrich- 
tigung) : 

• Information, ob der Empf anger verstanden hat, daS eine 
zuvor durch eine Benachrichtigung angekiindigte MM A nun 

5 nicht mehr zum Download bereitliegt. 

oder: 

• Information, ob das MMS User Agent B den Riickruf (d.h. 
das Loschen) der MM A erfolgreich durchfiihren konnte 
bzw. veranlaSt hat. 

10 • Information, ob der Empf anger daruber informiert wurde 
(und/oder dem Riickruf zugestimmt hat) , daS eine be- 
reits heruntergeladene MM A zuruckgeruf en wurde und da- 
her nicht mehr im dem MMS User Agent B zugangigen 
Speicher des Endgerats (oder angeschlossenener Gera- 

15 te/Speicherkarten) vorliegt. 

MMS Relay B MMS Relay A (nur dann notig, wenn Absender 
und Empfanger zu unterschiedlichen MMSEs gehoren und wenn 
der Absender eine Riickmeldung angefordert hat) : 
20 • Information, ob der Riickruf -Auftrag erfolgreich ausge- 
ftihrt werden konnte. 

• Information, wann der Riickruf -Auftrag ausgefiihrt wor- 
den ist. 

• Information, ob der Riickruf -Auftrag automatisch durch- 
25 gefuhrt wurde. 

• Information, ob der Empfanger uber den Riickruf infor- 
miert wurde (und/oder dem Riickruf zugestimmt hat) . 

• Information, da£ eine bereits heruntergeladene MM A zu- 
ruckgerufen wurde und daher nicht mehr im dem MMS User 

30 Agent B zugangigen Speicher des Endgerats (oder an- 

geschlossenener Gerate/Speicherkarten) vorliegt . 
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• Identif ikationsnummer der MM A , die zuruckgeruf en wurde 

MMS Relay A — » MMS User Agent A (beim Bericht) : 

• Information, ob der Ruckruf -Auf trag erfolgreich ausge- 
fuhrt werden konnte. 

• Information, wann der Ruckruf -Auf trag ausgeftihrt wor- 
den ist. 

• Information, ob der Ruckruf -Auf trag automatisch durch- 
gefiihrt wurde. 

• Information, ob der Empf anger liber den Ruckruf infor- 
miert wurde (und/oder dem Ruckruf zugestimmt hat) . 

• Information, daS eine bereits heruntergeladene MM A zu- 
ruckgerufen wurde und daher nicht mehr im dem MMS User 
Agent B zugangigen Speicher des Endgerats (oder an- 
geschlossenener Gerate/Speicherkarten) vorliegt. 

• Identif ikationsnummer der MM A , die zuruckgeruf en wur- 
de . 

Nachfolgend werde mogliche Modif ikationen der WAP Nach- 
richten fur das Ruckruf -Dienstmerkmal naher erlautert: Um 
das Ruckruf -Dienstmerkmal in die WAP Implementierung von 
MMS einzufiigen, schlagt die vorliegende Erfindung eine 
Modif ikation der WAP Nachrichten M-Send. req, M-Send. conf , 
M-Notification.ind, M-NotifyResp.req und M-Delivery. ind 
vor. In ihnen konnen nach dieser Erfindung verschiedene 
Header-Felder erganzt bzw. modifiziert werden. Nach WAP- 
203-WSP, Version 4-May-2000, Wireless Application Proto- 
col, Wireless Session Protocol Specification, Chapter 
8.4: "Header Encoding" besteht jedes Header-Feld aus ei- 
nem (kodierten) Feld-Namen und einem (kodierten) Feld- 
Wert. Dabei existieren insgesamt vier Moglichkeiten den 
Feld-Wert zu codieren, wobei das erste Oktet des Feld- 
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Wertes tiber die Art und Lange der Codierung entscheidet 
(siehe Tabelle 1 im Anhang) . 

A.l. WAP Nachricht M-Send.req (vom MMS User Agent A zum 
MMS Relay A) 

Der Absender einer MM A soil zum Ausdruck bringen, da£ er 
seine MM A wieder zuruckrufen mochte. Dies geschieht durch 
das Versenden einer weiteren MM B an den gleichen Empfan- 
ger. Zu diesem Zwecke kann in der WAP Nachricht M- 
Send.req, mit der die MM B verschickt wird, ein Header- 
Feld erganzt werden, das die Identif ikationsnummer derje- 
nigen MM tragt, die der Absender zuruckrufen mochte (ID1 
von MM A aus Fig. 2) . Es wird vorgeschlagen, daS dieses 
Header-Feld den Namen X-Mms -Recall -ID und die hexadezima- 
le Codierung 0x7F (dezimal: 127) tragt. Message-IDs wer- 
den konform zum Encapsulation-Standard (WAP-2 09- 
MMSEncapsulation, Release 2000; Wireless Application Pro- 
tocol; WAP Multimedia Messaging Service; Message Encapsu- 
lation; MMS Proposed SCD 1.0) vorzugsweise als Text- 
String codiert. AuSerdem kann dem Absender einer MM mit 
Ruckruf-Auftrag bevorzugt die Moglichkeit gegeben werden, 
eine Ruckmeldung anfordern zu konnen. Dazu wird vorge- 
schlagen, ein Header-Feld mit der zweckmaSigen Bezeich- 
nung X-Mms -Request -Report und der hexadezimalen Codierung 
0x85 (dezimal: 133) in die WAP Nachricht M-Send.req ein- 
zufuhren. Die Feld-Werte dieses Header-Feldes sind bevor- 
zugt konform zum Encapsulation-Standard (s.o.) mit dem 
<Octetl28> fur ^Ruckmeldung wird gewunscht" und <Oc- 
tetl29> fur „Riickmeldung ist nicht erwiinscht" codiert. 

A. 2 WAP Nachricht M- Send, conf (vom MMS Relay A zum MMS 
User Agent A) 
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Mit dieser WAP Nachricht kann dem MMS User Agent A gemaS 
der vorliegenden Erfindung zusatzlich mitgeteilt werden, 
ob der Service Provider A den Rtickruf -Auf trag des Absen- 
ders (MMS User Agents A) angenommen hat. Dazu wird vor- 
teilhaf terweise vorgeschlagen, ein neues Header-Feld mit 
den Namen X-Mms- Support ed-Feature und der hexadezimale 
Codierung 0x83 (dezimal: 131) in die WAP Nachricht M- 
Send. conf einzuftigen. Vorzugsweise werden als Feld-Werte 
konform zum Encapsulation-Standard (s.o.) das <Octetl28> 
fur eine Auf tragsbestatigung und das <Octetl3 0> fur eine 
negative Ruckmeldung benutzt (vergleiche Fig. 5) . 

A. 3 WAP Nachricht M-Notification.ind (vom MMS Relay B 
zum MMS User Agent B) 

1st das MMS User Agent B bereits iiber eine zum Download 
bereitliegende MM A informiert worden, kann gemaS der vor- 
liegenden Erfindung in der WAP Nachricht M- 
Notification.ind ein neu definiertes Header-Feld mit der 
zweckmaSigen Bezeichnung X-Mms-Recalled-URI und der hexa- 
dezimalen Codierung 0x80 (dezimal: 128) zum Einsatz kom- 
men. Mit seiner Hilfe kann dem MMS User Agent B' mitge- 
teilt werden, daS die MM A mit dem angegebenen URI nicht 
mehr langer zum Download bereit liegt, weil sie der Ab- 
sender wieder zuruckgeruf en hat. Der Feld-Wert dieses neu 
definierten Header-Feldes wird bevorzugt konform zum En- 
capsulation-Standard (s.o.) als Text-String codiert . 
Urn den MMS User Agent B uber den Zeitpunkt des Loschens 
informieren zu konnen, kann gemafi dieser Erfindung ein 
neu definiertes Header-Feld mit der zweckmaSigen Bezeich- 
nung X-Mms-Date-of -Execution und der hexadezimalen Codie- 
rung 0x84 (dezimal: 132) erganzt werden. Die Feld-Werte 
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fur dieses Header-Feld werden bevorzugt nach dem Encapsu- 
lation-Standard (s.o. ) als Long-Integer codiert. 

In der URI der Benachrichtigung kann gemaS der vorliegen- 
5 den Erfindung auf den Speicherplatz einer Standard-Text- 
Nachricht (z. B.: „Diese MM wurde vom Absender wieder ge- 
loscht.") verwiesen werden, mit der das MMS Relay B auch 
ein MMS User Agent B uber einen ausgefuhrten Riickruf - 
Auftrag informieren kann, wenn dies das Riickruf - 
10 Dienstmerkmal nicht unterstiitzt (also die neuen Header- 
Felder nicht erkennt) und versucht, eine MM von dem in 
der Benachrichtigung ausgewiesenen Speicherplatz herun- 
terzuladen. 

15 Falls die MM A/ die zuruckgeruf en werden soli, bereits an 
das MMS User Agent B ausgeliefert worden ist, kann erf in- 
dungsgemafi die WAP Nachricht M-Notification . ind das in 
Abschnitt A.l definierte Header-Feld mit dem Namen X-Mms- 
Recall-ID beinhalten. Das MMS User Agent B kann daraufhin 

20 umgehend mit Hilfe der Message-ID (ID2 aus Fig. 2) das 
Loschen der MM A einleiten ( vorausgesetzt es unterstiitzt 
das Riickruf -Dienstmerkmal) . 

A. 4 WAP Nachricht M-NotifyResp.req (vom MMS User Agent B 
25 zum MMS Relay B) 

GemaS der vorliegenden Erfindung wird vorteilhaf terweise 
vorgeschlagen, in der WAP Nachricht M-NotifyResp.reg op- 
tional ein neues Header-Feld einzufiigen, mit dessen Hilfe 
30 dem MMS Relay B mitgeteilt werden kann, ob das MMS User 
Agent B die Meldung liber einen erfolgreich ausgefuhrten 
Riickruf -Auf trag verstanden hat. Zu diesem Zweck wird vor- 
zugsweise das aus anderen WAP Nachrichten bekannte Hea- 
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der-Feld X-Mms-Status benutzt und ein neuer Feld-Wert de- 
finiert: Es wird vorgeschlagen, daS das <Octetl36> die 
Bedeutung „ Recall -Feature supported" hat. 

5 Falls die ruckzuruf ende MM A bereits an das MMS User Agent 
B ausgeliefert worden war, wird gemaS einer vorteilhaf ten 
Variante der vorliegenden Erfindung vorgeschlagen, in der 
WAP Nachricht M-NotifyResp.req das im Encapsulation- 
Standard (s.o.) definierte Header-Feld X-Mms-Status ein- 

10 zuftigen, mit dem dem MMS Relay mitgeteilt werden kann, ob 
der Ruckruf-Auf trag des Absenders erfolgreich auf dem MMS 
User Agent B ausgefuhrt werden konnte oder nicht. Dazu 
ist allerdings auch hier eine Erweiterung dieses Header- 
Feldes notwendig: Die Ruckmeldung wird bevorzugt mit den 

15 beiden neuen Feld-Werten <Octetl32> fur „Ruckruf -Auf trag 
wurde erfolgreich ausgefuhrt" und <Octetl33> fiir Ruck- 
ruf-Auf trag konnte nicht ausgefuhrt werden" realisiert. 

A. 5 WAP Nachricht M-Delivery . ind (vom MMS Relay A zum 
20 MMS User Agent A) 

Weiterhin wird vorgeschlagen, vorzugsweise das in Ab- 
schnitt A. 4 erweiterte Header-Feld X-Mms-Status auch hier 
einzufiigen. Mit seiner Hilfe kann dem Absender (MMS User 

25 Agent A) mitgeteilt werden, ob sein Ruckruf-Auf trag er- 
folgreich ausgefuhrt werden konnte oder nicht, wenn auch 
hier die neuen Feld-Werte <Octetl32> fur „Ruckruf -Auf trag 
wurde erfolgreich ausgefuhrt" und <Octetl3 3> fur „Ruck- 
ruf-Auftrag konnte nicht ausgefuhrt werden" benutzt wer- 

30 den (vergleiche Fig. 5) . Aufierdem kann der Absender iiber 
das Datum der Ausfiihrung seines Riickruf -Auf trages mit 
Hilfe des in Abschnitt A. 3 definierten Header-Feldes mit 
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der zweckmafiigen Bezeichnung X-Mms-Date-of -Execution in- 
formiert werden. 

B ) Andern- Diens tmerkmal : 

5 

Ein Benutzer des MMS, der eine Multimedia Message MM A ab- 
geschickt hat und diese bereits verschickte MM spater 
verandern mochte, kann gemaS dieser Erfindung eine neue 
MM B zusammen mit der Information verschicken, daS diese 
10 MM B eine zuvor verschickte MM A andern, insbesondere er- 
setzen, soli . Unten stehende Ausfuhrungen gelten ganz 
allgemein fur Anderungen einer ersten Nachricht MM A , so 
auch z.B. fur das nachtragliche Anhangen einer Datei an 
eine zuvor versendete MM A . 

15 

Eine Anderung von MM A kann dadurch realisiert werden, daS 
der Absender eine neue MM B verfaSt, die einen Anderungs- 
befehl beinhaltet, und diese an den gleichen Empf anger 
wie die zuvor verschickte MM A schickt. Zur Identifizie- 

20 rung der MM A wird vorteilhaf erweise die IDl der zuvor 
verschickten und jetzt zu verandernden MM A benutzt. Die 
MM B mit der Anderungs- Information gelangt zunachst zum 
MMS Relay A. Hier wird uberpruft, ob die MM A mit der IDl 
noch im Zustandigkeitsbereich (MMSE A ) des Service Provi- 

25 ders A ist, oder ob sie sich schon im MMSE B des Service 

Providers B befindet. Beides ist moglich, je nach dem, ob 
vom Absender der MM A ein Zeitpunkt fur die f ruhestmogli- 
che Auslieferung oder eine Gultigkei tsdauer angegeben 
worden ist. Sobald die MM A in einem MMSE der beteiligten 

30 MMS Service Provider ausfindig gemacht worden ist, kann 
das Andern der MM A durch die MM B vom zustandigen MMS Re- 
lay eingeleitet werden, Praktisch realisiert wird diese 
Aktion vorzugsweise durch das Loschen der alten MM A und 
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das Weiterleiten der neuen . MM B an den Empfanger. Der MMS 
Service Provider hat gemaS dieser Erfindung die Moglich- 
keit, den MMS User Agent B liber einen gegebenenf alls aus- 
gefuhrten Anderungs -Vorgang und/oder iiber das Datum der 
5 Ausfuhrung des Anderungs - Vorgangs („diese MM wurde aktua- 
lisiert am...") in Kenntnis zu setzen. 

Hat der Empfanger (MMS User Agent B) der MM A noch keine 
Benachrichtigung iiber die MM A erhalten, etwa weil die MM B 

10 mit dem Anderungs -Au ft rag das MMS Relay B vor der zu an- 
dernden MM A erreicht, muS dieser auch nicht zwingend iiber 
eine vom Absender eingeleitete Anderungs -Akt ion infor- 
miert werden. Statt dessen kann das MMS Relay B warten, 
bis es die zu andernde MM A erhalt und andert, insbesonde- 

15 re ersetzt, diese beim Eintreffen durch die MM B (voraus- 
gesetzt, das MMS Relay B unterstutzt das Riickruf -Dienst- 
merkmal) . Der MMS Service Provider kann nach dieser Er- 
findung das MMS User Agent B bei der Zustellung der MM B 
davon in Kenntnis setzen, daS sie eine vom Absender nach- 

20 traglich geanderte MM ist und wann diese Anderung ausge- 
fiihrt worden ist. 

Falls das MMS User Agent B des Empfangers schon iiber die 
fur ihn im MMSE B bereitliegende MM A mittels einer Benach- 

25 richtigung (Notification) informiert worden ist und sich 
die MM A noch im Zustandigkeitsbereich des Service Provi- 
ders B befinden sollte, kann gemaS dieser Erfindung das 
MMS User Agent B mit einer erneuten Benachrichtigung (No- 
tification) davon in Kenntnis gesetzt werden, daS der Ab- 

30 sender seine MM A nachtraglich geandert hat und wann diese 
Anderung ausgefuhrt worden ist. 

Sollte die MM A schon an den Empfanger ausgeliefert worden 
sein, so kann entweder das MMS User Agent B zunachst eine 
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Benachrichtigung vom Service Provider B erhalten, daS ei- 
ne MM B zum Ersatz der MM A vorliegt, oder die MM B mit dem 
Anderungs-Auf trag kann dem MMS User Agent B unmittelbar 
zugestellt werden. Unabhangig davon, ob die MM B im PUSH- 
5 Modus oder im PULL-Modus zugestellt worden ist, kann das 
Andern, insbesondere das Ersetzen, der MM A durch die MM B 
direkt im MMS User Agent B stattfinden, sofern dies das 
Andern-Dienstmerkmal unterstutzt. Je nach Implementierung 
dieses Dienstmerkmals im Endgerat, den Einstellungen des 

10 Benutzers, den Einstellungen des Service Providers 

und/oder des Netzbetreibers kann das Andern, insbesondere 
das Ersetzen, von MM A (und damit im Falle des PULL-Modus: 
zusatzlich das Anfordern von MM B ) im Endgerat davon ab- 
hangig sein, ob die MM A bereits vom Empfanger „angefa£t u 

15 (z.B. geoffnet, gelesen, weitergeleitet , etc.) worden 

ist. Sinnvoll erscheint, insbesondere solche MMs automa- 
tisch (d.h. ohne Ruckfrage mit dem Empfanger) zu andern, 
welche noch nicht vom Empfanger „angefa£t u worden sind. 
Hat der Empfanger die MM A schon aus der Posteingangsbox 

20 genommen, weitergeleitet oder gelesen, so kann er zumin- 
dest noch daruber informiert werden, daS der Absender mit 
MM B die zuvor verschickte MM A andern wollte. 

Der Absender /Auf traggeber (MMS User Agent A) kann gemaS 
25 einer vorteilhaf ten Variante der Erfindung uber den Aus- 
gang und das Datum der Ausfiihrung der von ihm eingeleite- 
ten Anderungs-Aktion informiert werden, wenn die betei- 
ligten MMS Service Provider dies unterstutzen . 

30 Die Identif ikation von MM A auf der Empf angsapplikation 
MMS User Agent B) kann insbesondere anhand einer Nach- 
richtenref erenz erfolgen, welche vorzugsweise ein URI 
ist, unter dessen Speicherplatz eine Standard-Text- 
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Nachricht des empf angerseitigen Service Providers B abge- 
speichert ist. Die URI setzt sich bevorzugt aus der Iden- 
tif ikationsnummer ID1 von MM A oder aus von einer empfan- 
gerseitigen Netzwerkelement (MMS Relay B) festgelegten 
5 zweiten Identif ikationsnummer (ID2) zusammen. 

Um das gerade beschriebene Dienstmerkmal Andern, insbe- 
sondere Ersetzen, umsetzen zu konnen, wird gemaS der vor- 
liegenden Erfindung vorgeschlagen, daS eine oder mehrere 
10 der folgenden Inf ormationen zusatzlich zwischen den be- 
teiligten Instanzen (MMS User Agent A, MMS Relay A, MMS 
v Relay B und MMS User Agent B) ausgetauscht werden: 

MMS User Agent A — » MMS Relay A (beim Versenden einer 
15 MM) : 

• Kennzeichnung, dafi es sich bei einer MM B um einen An- 
derungs-Bef ehl handelt. 

• Identif ikationsnummer der MM A , die geandert werden 
soil . 

20 • Information, daS der Absender eine Ruckmeldung uber 

den Ausgang der von ihm eingeleiteten Anderungs-Aktion 
anf ordert . 

MMS Relay A -> MMS User Agent A (bei der Bestatigung nach 
25 dem Versenden einer MM) : 

• Mitteilung des Service Providers, ob dieser das An- 
dern- Di ens tmer kma 1 unterstiitzt . 

MMS Relay A -> MMS Relay B (nur dann no tig, wenn Absender 
30 und Empfanger zu unterschiedlichen MMSEs gehoren) : 

• Kennzeichnung, dafi es sich bei einer MM B um einen An- 
derungs-Bef ehl handelt . 
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• Identif ikationsnummer der MM A/ die geandert werden 
soil. 

• Information, daS der Absender eine Ruckmeldung uber 
den Ausgang der von ihm eingeleiteten Anderungs-Aktion 

5 anfordert 

Die Ubermittlung der Inf ormationen zwischen MMS Relay A 
und MMS Relay B ist davon abhangig, ob diese Inf ormatio- 
nen beim Versenden der MM B vorhanden waren. 

MMS Relay B MMS User Agent B (bei der Benachrichtigung 
uber eine eingetrof f ene MM) , vorzugsweise in einer Nach- 
richt : 

• Information, dafi der Absender eine zum Download be- 
reitliegende MM A durch eine neue MM B geandert hat. Die 
Identif izierung beider MMs erfolgt anhand der Message 
References (URIs) zu den betroffenen MMs. 

• Information, wann die zum Download bereitliegende MM A 
durch die neue MM B geandert wurde. 
oder: 

• Information, daS der Absender eine bereits zuvor aus- 
gelieferte MM A durch eine neue MM B andern, insbesondere 
ersetzen, mochte. Die Identif izierung der MM A , die ak- 
tualisiert wird, erfolgt anhand der individuellen Mes- 
sage ID und die Identif izierung der MM B , welche die MM A 
andern, insbesondere ersetzen, soil, erfolgt anhand 
der Message Reference (URI) . 

MMS User Agent B MMS Relay B (nach der Benachrichti- 
gung) : 

30 • Information, ob der Empf anger uber den Anderungs- 
Auftrag informiert werden konnte. 
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Wurde im Fall des PULL-Modus der Empfanger von einer vor- 
liegenden MM B mit Anderungs-Auf trag unterrichtet , so kann 
er diese mittels der bekannten Mechanismen vom MMS Relay 
B beziehen. Im Fall des PUSH-Modus wird der Download der 
5 MM B vom MMS Service Provider (und nicht vom Empfanger i - 
nitiiert) . In diesem Fall konnen die beiden vorigen 
Schritte (Benachrichtigung und deren Bestatigung) entfal- 
len. 

10 MMS Relay B —> MMS User Agent B (bei der Zustellung einer 
MM) : 

• Kennzeichnung, daS die MM B einen Anderungs-Auf trag 
enthalt, der auf dem MMS User Agent B ausgefuhrt wer- 

15 den soli. 

• Information, welche bereits ausgelief erte MM A gean- 
dert, insbesondere ersetzt, werden soil. Die Identifi- 
zierung der MM A erfolgt anhand der individuellen Mes- 

20 sage ID. 

Oder: 

• Information, daS die soeben ausgelief erte MM B eine 
nachtraglich geanderte MM ist. 

25 

• Information, wann MM B vom Absender geandert worden 
ist. 

MMS User Agent B — > MMS Relay B (nach der Zustellung ei- 
30 ner MM) : 
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• Information, ob der Anderungs-Auf trag erfolgreich aus- 
gefuhrt werden konnte . 

• Information, ob der Anderungs-Auf trag automat isch 
durchgefuhrt wurde. 

• Information, ob der Empf anger uber den Ande rungs -Vor- 
gang informiert wurde (und/oder der Anderung zuge- 
stimmt hat) . 

MMS Relay B — > MMS Relay A (nur dann notig, wenn Absender 
und Empf anger zu unterschiedlichen MMSEs gehoren und wenn 
der Absender eine Ruckmeldung angefordert hat) : 

• Information, ob der Anderungs-Auf trag erfolgreich aus- 
gefiihrt werden konnte. 

• Information, wann der Anderungs-Auf trag ausgefuhrt 
worden ist. 

• Information, ob der Anderungs-Auf trag automatisch 
durchgefuhrt wurde . 

• Information, ob der Empf anger uber die Anderung infor- 
miert wurde (und/oder der Anderung zugestimmt hat) . 

• Information, ob eine bereits heruntergeladene MM A ge- 
andert, insbesondere ersetzt, wurde oder aber die MM A 
vor dem Ersetzen noch nicht ausgeliefert worden war. 

• • Identif ikationsnummer der MM A , die geandert, insbeson- 

dere ersetzt, wurde. 
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MMS Relay A MMS User Agent A (beim Bericht) : 

• Information, ob der Anderungs-Auf trag erfolgreich aus- 
5 gefiihrt werden konnte . 

• Information, wann der Anderungs-Auf trag ausgefiihrt 
worden ist. 

10 • Information, ob der Anderungs-Auf trag automatisch 
durchgefiihrt wurde. 

• Information, ob der Empf anger iiber die Anderung infor- 
miert wurde (und/oder der Anderung zugestimmt hat) . 

15 

• Information, ob eine bereits heruntergeladene MM A ge- 
andert, insbesondere ersetzt, wurde oder aber die MM A 
vor der Anderung noch nicht ausgeliefert worden war. 

20 • Identif ikationsnummer der MM A/ die geandert, insbeson- 
dere ersetzt, wurde. 

Nachfolgend werde mogliche Modif ikationen der WAP Nach- 
25 richten fur das Andern-Dienstmerkmal naher erlautert : Um 
das Andern-Dienstmerkmal in die WAP Implement ierung von 
MMS einzufuhren, wird gemaS der vorliegenden Erfindung 
eine Modif ikation der WAP Nachrichten M-Send. reqr, M- 
Send.conf, M-Notification.ind, M-NotifyResp.req, M- 
30 Retrieve, con f, M-Acknowledge . ind und M-Delivery. ind vor- 
geschlagen. In ihnen werden vorteilhaf terweise analog zum 
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Vorgehen in Abschnitt A (Rtickruf -Dienstmerkmal ) verschie- 
dene Header-Felder erganzt bzw. modif iziert : 

B.l WAP Nachricht M-Send.req (vom MMS User Agent A zum 
MMS Relay A) 

Der Absender einer MM soil zum Ausdruck bringen konnen, 
daS er nachtraglich seine bereits verschickte MM A durch 
eine neue MM B andem, insbesondere ersetzen, mochte. Be- 
vorzugt wird zu diesem Zweck in der WAP Nachricht M- 
Send.req, mit der die neue MM B verschickt wird, ein wei- 
teres Header-Feld erganzt, das die Identif ikationsnummer 
derjenigen MM tragt, die durch MM B geandert, insbesondere 
ersetzt, werden soli (namlich ID1 von MM A aus Fig. 2) . Es 
wird vorgeschlagen, dag dieses Header-Feld den Namen X- 
Mms-Replace-ID und die hexadezimale Codierung 0x81 (dezi- 
mal: 12 9) tragt. Message- IDs werden konform zum Encapsu- 
lation-Standard (s.o.) vorzugsweise als Text-String co- 
diert. AuSerdem wird dem Absender einer MM mit Anderungs- 
Auftrag vorzugsweise die Moglichkeit gegeben, eine Ruck- 
meldung anzufordern. Dazu wird vorgeschlagen, das in Ab- 
schnitt A.l definierte Header-Feld mit der zweckmafiigen 
Bezeichnung X-Mms -Request -Report in die WAP Nachricht M- 
Send.req einzufuhren. Die Feld-Werte dieses Header-Feldes 
werden vorteilhaf terweise konform zum Encapsulation- 
Standard (s.o.) mit dem <Octetl28> fur „Ruckmeldung wird 
gewiinscht" und <Octetl29> fur „Ruckmeldung ist nicht er- 
wunscht" codiert . 

B.2 WAP Nachricht M-Send. conf (vom MMS Relay A zum MMS 
User Agent A) 



200100797 

35 

Mit dieser WAP Nachricht kann dem MMS User Agent A gema£ 
der vorliegenden Erfindung mitgeteilt werden, ob der Ser- 
vice Provider A dem Anderungs-Auf trag des Absenders (MMS 
User Agents A) entsprechend gehandelt hat bzw. handeln 

5 konnte. Dazu wird vorgeschlagen, das in Abschnitt A. 2 zum 
Zwecke des Riickruf -Dienstmerkmals eingefuhrte Header-Feld 
mit der zweckmaSigen Bezeichnung X-Mms-Supported-Feature 
vorzugsweise auch hier zu nutzen. Als Feld-Werte kommen 
dann entweder das <Octetl29> fur „i?eplace-Feature suppor- 

10 ted" Oder das <Octetl3 0 > fur „no support" zum Einsatz. 




B.3 WAP Nachricht M-Notification.ind (vom MMS Relay B 



zum MMS User Agent B) 



15 Nach dieser Erfindung wird in der WAP Nachricht M- 

Notification. ind vorzugsweise ein neu definiertes Header- 
Feld mit der zweckmaSigen Bezeichnung X-Mms-Replaced-URI 
und der hexadezimalen Codierung 0x82 (dezimal: 130) er- 
ganzt. Mit seiner Hilfe kann dem MMS User Agent B nach 

20 einer bereits erfolgten Benachrichtigung mitgeteilt wer- 
den, daS die MM A unter dem angegebenen URI nicht mehr 
langer zum Download bereit liegt, weil sie der Absender 
durch eine neu MM B mit einem anderen URI ersetzt hat. Der 
Feld-Wert dieses neu definierten Header-Feldes wird vor- 

25 teilhaf terweise konform zum Encapsulation-Standard (s.o.) 
als Text-String codiert. Urn den MMS User Agent B uber den 
Zeitpunkt der Aktualisierung informieren zu konnen, wird 
gemaS einer vorteilhaf ten Variante der Erfindung das in 
Abschnitt A. 3 neu definierte Header-Feld mit der zweckma- 

30 Sigen Bezeichnung X-Mms-Date-of -Execution erganzt. 



Wenn sich die zu andernde, insbesondere zu ersetzende, 
MM A schon auf dem MMS User Agent B befindet, wird vor- 
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teilhaf terweise gemaS dieser Erf indung in der WAP Nach- 
richt M-Notification.ind das in Abschnitt B.l neu defi- 
nierte Header-Feld mit der zweckmaSigen Bezeichnung X- 
Mms-Replace-ID und der hexadezimalen Codierung 0x81 (de- 
5 zimal: 129) erganzt. Das MMS User Agent B erkennt daran, 
daS die zum Download bereitliegende MM B einen Anderungs- 
Befehl fur die MM A mit der entsprechenden Message-ID be- 
inhaltet. Der Download der MM B kann daraufhin je nach den 
Einstellungen des Benutzers, den Einstellungen des MMS 
10 Service Providers und/oder des Netzbetreibers entweder im 
Push-Modus oder im Pull -Modus eingeleitet werden. 

B.4 WAP Nachricht M-Retrieve. conf (vom MMS Relay B zum 
MMS User Agent B) 

15 

Wenn die zu andernde MM A schon im MMSE B durch MM B geandert 
werden konnte, bietet sich gemafi der vorliegenden Erf in- 
dung an, in der WAP Nachricht M- Re tri eve. conf , mit der 
MM B an den MMS User Agent B ubermittelt wird, vorzugswei- 

20 se das Encapsulation-Standard (s.o.) definierte erweiter- 
te Header-Feld X-Mms-Status mit dem Feld-Wert <Octetl34> 
fur ^replace successful" und das in Abschnitt A. 3 neu de- 
finierte Header-Feld mit der zweckmaSigen Bezeichnung X- 
Mms-Date-of -Execution einzufligen. Dadurch kann das MMS 

25 Relay B dem MMS User Agent B signalisieren, dafi die MM B 
eine nachtraglich geanderte MM ist und wann der Ande- 
rungs-Auf trag des Absenders im Zustandigkeitsbereich des 
MMSE B ausgefiihrt worden ist. 

30 Wenn sich die zu andernde MM A schon auf dem MMS User A- 
gent B befindet, ist es gemaS der vorliegenden Erfindung 
vorteilhaft, in der WAP Nachricht M-Re tri eve. conf eben- 
falls das in Abschnitt B.l definierte Header-Feld mit dem 
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Namen X-Mms -Replace- ID zu erganzen. Mit ihm kann das An- 
dern der MM A auf dem MMS User Agent B mit Hilfe der Mes- 
sage-ID eingeleitet werden (s. Fig. 2), falls das MMS U- 
ser Agent B das Andern-Dienstmerkmal unterstutzt. Andern- 
falls wird dem Empf anger dadurch nur angezeigt, date der 
Absender die MM A durch die neue MM B andern wollte. 

B.5 WAP Nachricht M- Acknowledge . ind (vom MMS User Agent 
B zum MMS Relay B) 

GemaS dieser Erfindung wird in einer vorteilhaf ten Wei- 
terbildung vorgeschlagen, in der WAP Nachricht M- 
Acknowledgement . ind das im Encapsulation-Standard (s.o.) 
definierte Header-Feld X-Mms-Status einzufugen. Damit dem 
MMS Relay mitgeteilt werden kann, ob der Anderungs- 
Auftrag des Absenders im PULL-Modus erfolgreich ausge- 
fiihrt werden konnte Oder nicht, ist auch hier eine Erwei- 
terung dieses Header-Feldes (analog zu dem Vorgehen in 
Abschnitt A, Riickruf -Dienstmerkmal ) notwendig: Die Ruck- 
meldung wird in dieser Erfindung vorteilhaf terweise mit 
den beiden neuen Feld-Werten <Octetl34> fur „Anderungs- 
Auftrag wurde erfolgreich ausgefuhrt" und <Octetl3 5> fur 
w Anderungs-Auftrag konnte nicht ausgefuhrt werden" reali- 
siert. 

B.6 WAP Nachricht M-NotifyResp.ind (vom MMS User Agent B 
zum MMS Relay B) 

GemaS dieser Erfindung wird vorgeschlagen, in der WAP 
Nachricht M-NotifyResp . ind das im Encapsulation-Standard 
(s.o.) definierte Header-Feld X-Mms-Status einzufugen. 
Damit dem MMS Relay mitgeteilt werden kann, ob der Ande- 
rungs-Auf trag des Absenders im PUSH-Modus erfolgreich 
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ausgefuhrt werden konnte oder nicht, ist auch hier eine 
Erweiterung dieses Header-Feldes (analog zu dem Vorgehen 
in Abschnitt A, Riickruf-Dienstmerkmal ) notwendig: Die 
Riickmeldung wird in dieser Erfindung vorzugsweise mit den 
beiden neuen Feld-Werten <Octetl34> fur „Anderungs- 
Auftrag wurde erfolgreich ausgefuhrt" und <Octetl35> fur 
„ Anderungs-Auf trag konnte nicht ausgefuhrt werden" reali- 
siert . 



B.7 WAP Nachricht M-Delivery. ind (vom MMS Relay A zum 
MMS User Agent A) 

Weiterhin wird vorgeschlagen, das in Abschnitt B.5 erwei- 
terte Header-Feld X-Mms-Status auch hier einzufugen. Mit 
seiner Hilfe kann dem Absender (MMS User Agent A) mitge- 
teilt werden, ob sein Anderungs-Auf trag erfolgreich aus- 
gefuhrt werden konnte oder nicht, wenn auch hier die neu- 
en Feld-Werte <Octetl34> fur „ Anderungs-Auf trag wurde er- 
folgreich ausgefuhrt" und <Octetl35> fur „Anderungs- 
Auftrag konnte nicht ausgefuhrt werden" benutzt werden 
(vergleiche Fig. 5) . AuEerdem wird der Absender vorteil- 
hafterweise tiber das Datum der Ausftihrung seines Ande- 
rungs-Auf trages mit Hilfe des in Abschnitt A. 3 definier- 
ten Header-Feldes mit der zweckmaSigen Bezeichnung X-Mms- 
Date-of -Execution inf ormiert . 

Fig. 5 zeigt noch einmal die sieben, vorteilhaf terweise 
neu eingefuhrten Header-Felder einschlieSlich der Codie- 
rungen von Feld-Name und Feld-Wert. In Fig. 6 ist das urn 
neue Feld-Werte erweiterte Header-Feld X-Mms -Status dar- 
gestellt. In den Fig. 7 und 8 sind die Header-Felder der 
alternativen Realisierungsmoglichkeiten (Ausf iihrungsbei- 
spiele C und D, s.u.) dargestellt. Die urn die entspre- 
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chenden Header-Felder erganzten WAP Nachrichten sind im 
Anhang in den Tabellen 2 bis 8 aufgelistet. Alle Verande- 
rungen und Erganzungen in den Tabellen zum heutigen Stand 
der Technik sind dabei dick eingerahmt . 

Binare Codierung 

In den folgenden Ausf iihrungsbeispielen wird detailliert 
auf die in den WAP Nachrichten benutzten Header-Felder 
eingegangen. Dabei wird beispielhaft folgendes Szenario 
angenommen : MMS User Agent A verschickt eine MM A beste- 
hend aus einem Text und einem JPEG-Bild an einen Empf an- 
ger und will diese spater zuruckrufen (Beispiel A) bzw. 
durch eine neue MM B ersetzen (Beispiel B) . 

M-Send.req (MMS User Agent A MMS Relay A) : 

X-Mms -Message - Typ e ; m-send- req 
X-Mms-Transaction-ID: 10 
X-Mms -Version: 1.0 

Date: Thu, 26 Oct 2000 12:12:19 -h0100 

From: abc@siemens.de 

To : xyz@siemens . de 

Subject: multimedia message a 

Content-Type: multipart /related; boundary=" 

_ =_Nex tPart_000_ " 

=_Nex tPart_000_ 

Content-Type : text/plain; name= "meeting . txt " 
Content-Transfer-Encoding : guoted-printable 



Hallo xyz, 
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hier ist die gewiinschte Agenda 
fiir unser nachstes Meeting. 

GruS, abc 

_ =_Nex tPart_000_ 

Content-Type: image/ jpeg; name= "agenda . jpg" 
Content-Transfer-Encoding: base64 
Content-ID: <1725782> 



__=_NextPart_000_-- 

Das MMS User Agent A des Benutzers mit der Adresse 
abc@siemens.de verschickt eine MM A bestehend aus einem 
Text (MIME content type „ text /plain" ) und einem JPEG-Bild 
(MIME content type „ image/ jpeg u ) an das MMS User Agent B 
des Benutzers mit der Adresse xyz@sieine12s.de. Die zu die- 
sem Zweck benutzte WAP Nachricht M-Send.req tragt bei- 
spielsweise die Transaction-IDIO . Das MMS Relay vergibt 
daraufhin eine individuelle Identif ikationsnummer fur die 
gesendete MM A und bestatigt mit der WAP Nachricht M- 
Send.conf, dag die WAP Nachricht M-Send.req fehlerfrei an 
das MMS Relay ubertragen worden ist. 

M-Send.conf (MMS Relay A -» MMS User Agent A) : 

X-Mms -Message-Type : m- send- con f 
X-Mms-Transaction-ID : 1 0 
X-Mms -Vers ion: 1.0 
X-Mms -Response- Status : ok 
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Message-ID: AAAA. Illl@mms-rela.y01 . Siemens . de 

In den beiden WAP Nachrichten M-Send. req und M-Send. conf 
kommt die gleiche Transaction-ID zum Einsatz. Damit kann 
die WAP Nachricht M-Send. conf mit der Message-ID am MMS 
User Agent A eindeutig der dazugehorigen WAP Nachrichten 
M-Send. req; zugeordnet werden, wodurch die individuelle 
Identif ikationsnummer AAAA. llllQmms -relay 01 . Siemens . de 
der verschickten MM A zugeordnet werden kann. Das MMS Re- 
lay A hat fur die MM A in diesem Beispiel fur die Schnitt- 
stelle MMS User Agent A / MMS Relay A die individuelle 
Identif ikationsnummer AAAA. llllQmms-relayOl . Siemens .de 
vergeben. Sie steht im Header-Feld Message-ID. 

Beispiel A: Ruckruf 

Der Absender der MM A mochte diese (zwei Stunden spater) 
wieder zuruckrufen. Dies geschieht nach dieser Erfindung 
mit Hilfe einer neuen MM B , die an den gleichen Empfanger 
geschickt wird, wie die MM A/ die zuriickgeruf en werden 
soil. An dieser Stelle kommt vorteilhaf terweise in der 
WAP Nachricht M-send.req das gemaS der vorliegenden Er- 
findung neu definierte Header-Feld mit der zweckmaSigen 
Bezeichnung X-Mms-Recall-ID zum Einsatz, in das die Mes- 
sage- ID der MM A , die zuriickgeruf en werden soil, eingetra- 
gen wird (ID1 in Fig. 2) . AuSerdem enthalt die WAP Nach- 
richt M-Send. req vorteilhaf terweise das ebenfalls gemaS 
der vorliegenden Erfindung neu definierte Header-Feld mit 
der zweckmaEigen Bezeichnung X-Mms -Request -Report , mit 
dem eine Ruckmeldung tiber den erteilten Ruckruf -Auftrag 
angefordert werden kann (wie in diesem Beispiel gezeigt) . 
In der WAP Nachricht M-Send. req sind bei einem Ruckruf- 
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Auftrag vorzugsweise nur die Header-Felder und kein wei- 
terer multimedialer Inhalt ( ^Message-Body") enthalten. 

M-Send.req (MMS User Agent A MMS Relay A) : 

X-Mms -Message - Type : m-send-req 
X-Mms- Tra nsaction-ID: 16 
X-Mms -Vers ion : 1.0 

Date: Thu, 26 Oct 2000 14:12:19 +0100 
From: abc&sal . Siemens . de 
To : xyz@sal . Siemens . de 



X-Mms -Recall -ID: AAAA . 


llll@mms- 


relay 01 . Siemens .de 




X-Mms -Request -Report : 


Yes 



Subject: recall of multimedia message a 



Content-Type: text/plain 

Auch der Empfang der WAP Nachricht M-Send.req mit dem 
Ruckruf-Befehl in MM B wird vorteilhaf terweise vom MMS Re- 
lay umgehend mit einer WAP Nachricht M-Send.conf quit- 
tiert. In ihr ist die vom MMS Relay vergebene Message-ID 
fur die MM B (hier: AAAA. 222 2Qmms -relay 01 . Siemens . de) ent- 
halten. Ferner enthalt sie vorteilhaf terweise das gemaS 
der vorliegenden Erfindung neu definierte Header-Feld X- 
Mms-Supported-Feature mit dessen Hilfe dem MMS User Agent 
A angezeigt werden kann, ob der Service Provider A das 
Ruckruf-Dienstmerkmal unterstutzt (wie hier gezeigt) oder 
nicht . 

M-Send.conf (MMS Relay A -> MMS User Agent A) : 
X-Mms -Message-Type: m-send-conf 
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X-Mms-Transaction-ID : 16 

X-Mms - Version : 1.0 

X-Mms -Response-Status : ok 

Message-ID: AAAA . 2222@mms-relay01 . Siemens . de 



X-Mms -Supported-Feature : 
recall 



Beim Austausch von WAP Nachrichten auf der Empf angsseite 
(Schnittstelle zwischen MMS Relay B und MMS User Agent B) 
10 muS unterschieden werden, ob der MMS User Agent B 

1. noch nicht liber eine eingetrof f ene MM informiert wor- 
den ist, oder 

2. zwar benachrichtigt worden ist, aber die MM noch 
nicht abgerufen hat, oder 

15 3. die MM schon erhalten hat. 



Im ersten und zweiten Fall konnen die MM A und auch die 
MM B/ die den Ruckruf -Bef ehl enthalt, im Zustandigkeitsbe- 
reich des Service Providers B (MMSE B ) geloscht werden. Im 

20 ersten Fall mufi der Empf anger davon nicht einmal in 

Kenntnis gesetzt werden. Im zweiten Fall sollte der MMS 
User Agent B hingegen durch den Service Provider B vor- 
zugsweise daruber informiert werden konnen, da6 die MM A 
nicht mehr langer zum Download fur ihn bereit liegt, wenn 

25 der Absender sie nachtraglich zuriickgeruf en hat. Dazu 
kann gemaS dieser Erfindung die WAP Nachricht M- 
Notification. ind benutzt werden: 

2. Fall: M-Notif ication . ind (MMS Relay B — > MMS User Agent 
30 B) : 



X-Mms -Mes sage- Type : m-notification-ind 
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X-Mms-Transaction-ID: 20 

X-Mms -Vers ion: 1.0. .. _ ... . . _ 

From : abc@sal . Siemens . de 

X-Mms-Message-Class : Personal 

X-Mms -Message -Size: 42 

X-Mms -Expiry : 3600 

X-Mms-Conten t -Loca tion: http: //mms - 
relay02 . Siemens . de/de fault-recall -message 
X-Mms-Recalled-URI : http : //mms- ~— 
relay 02 . Siemens . de/BBBB . 3333 

X-Mms-Date-Of -Execution: Thu, 26 Oct 2000 14:14:54 
+ 0100 



In der WAP Nachricht M-Notification. ind kann fur die I- 
dentif izierung der zuruckgerufenen MM A nur der URI be- 
nutzt werden, da das MMS Relay zu diesem Zeitpunkt noch 
keine Message-ID fur die zuruckgeruf ene MM A vergeben hat 
(dies geschieht erst mit dem Download) . Die Header-Feld 
X-Mms-Recalled-URI und X-Mms-Date-Of -Execution unter- 
scheiden diese Ruckruf -Benachrichtigung von einer „her- 
kommlichen" Benachrichtigung. Das Header-Feld X-Mms- 
Content-Location verweist in diesem Beispiel auf einen 
URI, unter dessen Speicherplatz vorteilhaf terweise eine 
Standard-Text-Nachricht des Service Providers B (z. B. : 
„Die MM ist vom Absender wieder geloscht worden. u ) zu 
finden ist. Damit konnen auch MMS User Agents, die die 
neuen Header-Felder des Ruckruf -Dienstmerkmals nicht ver- 
stehen, nachtraglich iiber einen ausgefuhrten Rlickruf- 
Auftrag informiert werden. 

Mit der WAP Nachrichten M-NotifyResp.req wird der korrek- 
te Empfang der WAP Nachricht M-Notification. ind besta- 
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tigt. Das Header-Feld X-Mms-Status tragt in diesem Bei- 
spiel einen der gemaiS der vorliegenden Erfindung neu de- 
finierten Eintrage (namlich „recall feature supported"), 
mit dem das MMS Relay B dariiber in Kenntnis gesetzt wer- 
5 den kann, da£ das MMS User Agent B die zweite Benachrich- 
tigung mit der Information tiber den Ruckruf verstanden 
hat. 



(noch) 2. Fall: M-Notif yResp . req (MMS User Agent B — > MMS 
10 Relay B) : 



X-Mms -Message-Type : m-notifyresp-req 
X-Mms -Transact ion- ID: 20 
X-Mms -Version : 1.0 



15 



X-Mms-Sta tus : recall feature 
supported 



Wenn aber die MM A , die geloscht werden soil, bereits an 
20 das-' MMS User Agent B ubermittelt worden ist (dritter 

Fall) , beinhaltet vorteilhaf terweise die WAP Nachricht Id- 
Notification . ind zweckmaSigerweise nicht die Benachrich- 
tigung uber den bereits erfolgten Ruckruf, sondern den 
Ruckruf -Befehl selbst und zwar in Form des Header-Feldes 
25 mit der zweckmaSigen Bezeichnung X-Mms -Recall -ID, in dem 
die I dent if ikationsnummer der MM A eingetragen wird, die 
zuruckgeruf en werden soil. Hier wird vorzugsweise die I- 
dentif ikationsnummer (und nicht der URI) benutzt, weil 
sie (in dem hier beschriebenen dritten Fall) nach dem zu- 
30 vor erfolgten Download sowohl dem MMS Relay B als auch 
dem MMS User Agent B bekannt ist. 
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3. Fall: M-Notif ication . ind (MMS Relay B MMS User A- 
gent B) : . . 

X-Mms -Message -Type : m-notification-ind 

5 X-Mms -Transact ion- ID : 25 

X-Mms -Vers ion : 1.0 

From : abc@sal . si emens . de 

X-Mms-Message-Class : Personal 

X-Mms -Message-Si ze: 42 

10 X-Mms-Expiry: 3600 

X-Mms-Content-Location: http: //mms- 

relay02 . Siemens . de/de fault-recall -message 

X-Mms-Recall-ID: BBBB . 3333@mms- ~ 

relay 02 . si emens . de 
1 5 — — — __________ 

Das Header-Feld X-Mms-Content-Loca tion verweist in diesem 
Beispiel auf einen URI, unter dessen Speicherplatz eine 
Standard-Text-Nachricht des Service Providers B (z.B.: 
„Der Absender mochte die MM mit der Message-ID 
20 BBBB.3333Qmms-relay02.siemens.de zuruckruf en . u ) zu finden 
ist. Damit konnen auch MMS User Agents, die die neuen 
Header-Felder des Riickruf -Dienstmerkmals nicht verstehen, 
nachtraglich liber einen vom Absender verschickten Ruck- 
ruf-Auftrag informiert werden. 

25 

Um hervorzuheben, dafi die MM A an dieser Schnittstelle ei- 
ne andere Message-ID tragen kann, wurde in diesem Ausfuh- 
rungsbeispiel als Wert BBBB.3333@mms-relay02.siemens.de 
gewahlt (entspricht ID2 von MM A in Fig. 2) . 

30 

(noch) 3. Fall: M-NotifyResp . req (MMS User Agent B MMS 
Relay B) : 
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X-Mms -Mes sage-Type : m-notifyresp-req 
X-Mms-Transaction-ID: 25 
X-Mms - Versi on: 1.0 



X-Mms - Status : recall suc- 
cessful 



Das MMS User Agent B schickt bei diesem Ausf uhrungsbei- 
spiel mit der WAP Nachricht M-NotifyResp.req eine Ruck- 

10 meldung zuriick an das MMS Relay B. Dazu wird vorteilhaft- 
erweise das in dieser Erfindung erweiterte Header-Feld X- 
Mms-Status aus dem Encapsulation-Standard (s.o.) benutzt. 
In diesem Ausf uhrungsbeispiel konnte die MM A auf dem MMS 
User Agent B geloscht werden, was mit dem Feld-Wert „re- 

15 call successful'' ausgedruckt wird. Im MMS Relay B kann 
von der Transaction-ID (hier: 25) des WAP Nachrichten- 
Paares auf die Message-ID (hier: BBBB . 3333@mms- 
relay02.siemens.de) der geloschten MM A geschlossen wer- 
den. Dadurch ist das Verfassen einer Riickmeldung moglich, 

20 falls dies vom Absender gewiinscht und vom Service Provi- 
der B unterstiitzt wird. 

M-Delivery . ind (MMS Relay A — > MMS User Agent A) : 



25 



30 



X-Mms -Message - Type : m-del i very- ind 

X-Mms-Message-ID: AAAA . 2222@mms-relay01 . Siemens . de 

X-Mms -Vers ion : 1.0 

To : abcQsal . si emens . de 

Date: Thu, 26. Oct 2000 14:14:09 +0100 



X-Mms-Status : recall suc- 
cessful 
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Falls der Absender eine Riickmeldung fur den von ihm ini- 
tiierten Riickruf -Auf trag wiinscht, kann das MMS Relay A 
mit der WAP Nachricht M-Delivery. ind eine Riickmeldung zu 
ruck an das MMS User Agent A schicken. In dem Feld Messa 
ge-ID steht die ID des Riickruf -Auf t rages . Fur den Status 
des Ruckrufes wird hier ebenfalls vorteilhaf terweise das 
erweiterte Header-Feld X-Mms- Status benutzt, in dem das 
erfolgreiche Loschen der MM A mit dem Feld-Wert „recall 
successful" bestatigt wird. Da dem MMS User Agent A der 
Zusammenhang zwischen der Message-ID des Riickruf - 
Auftrages und der Message-ID der MM A , die zuriickgeruf en 
werden sollte, bekannt ist, kann dem Absender mitgeteilt 
werden, ob sein Riickruf -Auf trag erfolgreich ausgeftihrt 
werden konnte Oder nicht (sofern die beteiligten MMS Ser- 
vice Provider dies unterstutzen) . 



Beispiel B: Andern 

In diesem Beispiel mochte der Absender seine MM A (eine 
Stunde nach dem Verschicken) aktualisieren : Von den ur- 
spriinglichen verschickten zwei Elementen soli nur noch 
das JPEG-Bild (MIME content type „ image / j peg" ) erhalten 
bleiben. AuSerdem soil der Betreff in „Agenda fiir unser 
Meeting" geandert werden. 

Gemafi dieser Erfindung wird eine neue MM B an den gleichen 
Empf anger geschickt wie die zuvor verschickte MM A , die 
geandert bzw. ersetzt werden soil. Dazu wird vorteilhaf t- 
erweise das gemafi der vorliegenden Erfindung neu defi- 
nierte Header-Feld mit der zweckmafcigen Bezeichnung x- 
Mms -Replace -ID benutzt, in das die Message-ID der MM A 
eingetragen wird. AuSerdem enthalt vorteilhaf terweise die 
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WAP Nachricht M-Send.req das ebenfalls gemafi der vorlie- 
genden Erfindung neu definierte Header-Feld mit der 
zweckmaSigen Bezeichnung X-Mms -Request -Report , mit dem 
eine Ruckmeldung tiber den erteilten Anderungs-Auf trag an- 
5 gefordert werden kann (wie in diesem Beispiel gezeigt) . 

M-Send.req (MMS User Agent A — » MMS Relay A) : 



X-Mms -Message-Type : m-send-req 



10 



X-Mms- Transact ion- ID: 32 



X-Mms - Versi on: 1.0 



Date: Thu, 26 Oct 2000 13:12:11 +0100 



From : abc&sal . si emens . de 



To : xyzQsal . Siemens . de 



15 



X-Mms-Replace-ID: AAAA. llllQmms- 

// 

relayVl . Siemens . de 



X-Mms -Request -Report : Yes 



Subject: Agenda fur unser Meeting 
Content-Type : multipart /related; boundary- " 



20 



=_NextPart_023_ " 



=_Nex tPart_023. 



Content-Type : image/ j peg; name= "agenda . jpg " 
Content-Transfer-Encoding: base64 



25 



Con tent -ID: <1725782> 



=_NextPart_ 023 _ - - 



30 Auch der Empfang dieser WAP Nachricht M-Send. req, welche 
die MM B mit dem Anderungs-Bef ehl in sich tragt, wird be- 
vorzugt vom MMS Relay umgehend mit einer WAP Nachricht M- 
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Send. conf quittiert. In ihr ist zweckmaSigerweise die vom 
MMS Relay vergebene Message-ID der MM B (hier: 
AAAA. 5555@mms-relay01 . Siemens .de) und das ebenfalls gemafi 
der vorliegenden Erfindung neu definierte Header-Feld X- 
Mms-Supported-Feature enthalten, mit dessen Hilfe dem MMS 
User Agent A angezeigt werden kann, ob der Service Provi- 
der A das Andern-Dienstmerkmal unterstiitzt Oder nicht. 
Die beiden WAP Nachrichten tragen in diesem Beispiel die 
Transaction-ID32 . 

M-Send.conf (MMS Relay A — » MMS User Agent A) : 

X-Mms -Message-Type : m-send-conf 
X-Mms-Transaction-ID: 32 
X-Mms -Vers ion : 1 . 0 
X-Mms-Response-Status : ok 

Message-ID: AAAA. 5555@mms-relay01 . Siemens . de 

X-Mms - Support ed-Feature : 

replace 



Beim Austausch von WAP Nachrichten auf der Empf angsseite 
(Schnittstelle zwischen MMS Relay B und MMS User Agent B) 
mufi unterschieden werden, ob der MMS User Agent B 

1. noch nicht uber eine eingetrof f ene MM informiert wor- 
den ist, oder 

2. zwar benachrichtigt wordien ist, aber die MM noch 
nicht abgerufen hat, oder 

3. die MM schon erhalten hat. 

Im ersten und zweiten Fall kann die MM A im Zustandig- 
keitsbereich des Service Providers B (MMSE B ) durch die 
MM B geandert, insbesondere ersetzt, werden. Die Erfindung 
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ermoglicht, daS der Empf anger im ersten Fall sowohl bei 
der Benachrichtigung als auch beim Download daruber in 
Kenntnis gesetzt wird, daS es sich um eine nachtraglich 
geanderte, insbesondere ersetzte, MM handelt und wann der 
5 Anderungs-Auf trag ausgefuhrt worden ist. Bevorzugt kann 
im zweiten Fall der Service Provider B den MMS User Agent 
B sofort nach dem Ausfiihren des Anderungs-Auf trages im 
MMSE B daruber informieren, daS der Absender MM A durch ei- 
ne neue MM B aktualisiert hat und wann diese Aktualisie- 

10 rung vorgenommen worden ist. Nach dieser Erfindung soli 
diese Benachrichtigung vorzugsweise mittels der WAP Nach- 
richt M-Notification. ind erfolgen, in der fur die Identi- 
fizierung der geanderten, insbesondere ersetzten, MM A nur 
der URI benutzt werden kann, da das MMS Relay B zu diesem 

15 Zeitpunkt noch keine Message-ID fur die MM A vergeben hat 
(dies geschieht erst mit dem Download der MM A ) . Die Hea- 
der-Felder X-Mms-Replaced-URI und X-Mms-Date-Of -Execution 
unterscheiden diese Ruckruf -Benachrichtigung von einer 
„herkommlichen" Benachrichtigung. Das Header-Feld X-Mms- 

20 Content-Location zeigt an, wo die MM B mit dem nun aktuel- 
len Inhalt auf dem Server zu finden ist. 

2. Fall: M-Notif ication . ind (MMS Relay B — > MMS User A- 
gent B) : 

25 

X-Mms -Message - Type : m-notifi cation-ind 
X-Mms-Transact ion-ID : 35 
X-Mms - Versi on: 1.0 
From : abcQsal . si emens . de 
30 X-Mms-Message-Class : Personal 
X-Mms -Message-Size : 45 
X-Mms -Expiry: 3600 
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X-Mms -Con t en t -Loca tion: http: //wms - 
-relay 02 . Siemens .de/BBBB. 4444 



X-Mms -Replaced-URI : http: / Vmms- 
r el ay 02 . Siemens . de/BBBB. 3333 

X-Mms-Date-Of -Execution: Thu, 26 Oct 2000 13:15:09 
+ 0100 



Mit der WAP Nachricht M-NotifyResp.req wird vorteilhaf t- 
erweise der korrekte Empfang der WAP Nachricht M- 

10 Notification. ind vom MMS User Agent B bestatigt, vgl . 

Fig. 2. Das Header-Feld X-Mms-Status tragt in diesem Bei- 
spiel einen gemaS der vorliegenden Erfindung neu defi- 
nierten Eintrag (namlich ^replace feature supported"') mit 
dem das MMS Relay B daruber in Kenntnis gesetzt wird, daS 

15 das MMS User Agent B die zweite Benachrichtigung mit der 
Information uber den ausgefiihrten Anderungs-Auf trag ver- 
standen hat. 

(noch) 2. Fall: M-Notif yResp . req (MMS User Agent B — > MMS 
20 Relay B) : 



25 



X-Mms -Message - Type : m-noti fyresp -req; 
X-Mms-Transaction-ID: 35 
X-Mms - Versi on: 1.0 



X-Mms-Status : replace feature sup- 
ported 



Wenn aber die MM A , die geandert werden soli, bereits an 
30 das MMS User Agent B ubermittelt worden ist (dritter 

Fall), beinhaltet nach dieser Erfindung die WAP Nachricht 
M-Notification. ind vorteilhaf terweise nicht die Benach- 
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richtigung liber eine bereits erfolgte Anderung, sondern 
den Anderungs-Bef ehl selbst und zwar in Form des Header- 
Feldes mit der zweckmafiigen Bezeichnung X-Mms-Replace-ID t 
in dem die Identif ikationsnummer der zu andernden, insbe- 
sondere zu ersetzenden, MM A eingetragen wird. Daraufhin 
kann vom MMS User Agent B der Download der MM B entweder 
im Push-Modus oder im Pull-Modus mit Hilfe des WSP GET 
Befehls eingeleitet werden. Das Header-Feld X-Mms- 
Content-Location verweist in diesem Beispiel auf einen 
URI, unter dessen Speicherplatz eine Standard-Text - 
Nachricht des Service Providers B (z. B. : „Der Absender 
mochte die MM mit der Message-ID BBBB . 3333@mms- 
relay02.slemens.de nachtraglich andern.") zu finden ist. 
Damit konnen auch MMS User Agents, die die neuen Header- 
Felder des Ruckruf -Dienstmerkmals nicht verstehen, nach- 
traglich uber einen vom Absender verschickten Ruckruf- 
Auftrag informiert werden. 

3. Fall: M-Noti f ication . ind (MMS Relay B MMS User A- 
gent B) : 

X-Mms -Message-Type : m-notif ication- ind 

X-Mms-Transact ion-ID : 38 

X-Mms - Versi on: 1.0 

From : abc@sal . si emens . de 

X-Mms-Message-Class : Personal 

X-Mms -Message-Si ze: 45 

X-Mms -Expiry : 3 600 

X-Mms-Content-Location: http: //mms- 
relay02 . Siemens . de/default-replace-message 
X-Mms -Repl ace -ID: BBBB .3333 Qmms - ~" ™ ~ 
rel ay 02 . si emens . de 
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Als-Antwort auf den WSP GET Befehl, mit dem der URI an 
das MMS Relay B geschickt wird, erhalt das MMS User Agent 
B die MM B mit dem geanderten Titel und dem geanderten 
multimedialen Inhalt (nur noch ein JPEG-Bild) zum Andern 
bzw. Ersetzen von MM A in der WAP Nachricht M- 
Retrieve. conf zugestellt. Auch in der WAP Nachricht M- 
Retrieve. conf soil vorteilhaf terweise das Header-Feld mit 
der zweckmaSigen Bezeichnung X-Mms -Replace- ID erganzt 
werden. Damit kann direkt auf dem MMS User Agent B die 
MM A durch die MM B geandert, insbesondere ersetzt, werden, 
falls das MMS User Agent B das Andern-Dienstmerkmal un- 
terstutzt. Abhangig vom gewahlten Zustellungs-Modus wird 
in der WAP Nachricht M-Retrieve . conf die Transaction-ID 
aus der WAP Nachricht M-Notification.ind iibernommen 
(PUSH-Modus) oder eine neue vergeben (PULL-Modus) . 

(noch) 3. Fall: M-Retrieve . conf (MMS Relay B — > MMS User 
Agent B) : 

X-Mms -Message - Type : m-retri eve - con f 
X-Mms-Transaction-ID: 38 bzw. 48 
Message-ID: BBBB. 4444Qmms-relay02 . Siemens . de 
X-Mms - Version : 1.0 

Date: Thu, 26 Oct 2000 13:12:11 +0100 
From : abcQsal . si emens . de 
X-Mms-Message-Class : Personal 
X-Mms -Message-Size : 42 
X-Mms -Expiry : 3600 

X-Mms -Replace-ID: BBBB .3333 @mms - ^ "~ 
relay02 . si emens . de 

Subject: Agenda fur unser Meeting ™~ 
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Content-Type : multipart/related; boundary= " 

_=_NextPart_023_ " 

__=_NextPart_023_ 

Content-Type : image/ j peg; name= "agenda . jpg " 
Con ten t - Transfer-Encoding : base64 
Content-ID: <1725782> 

_ =_NextPar t_ 023 _ — 

Um hervorzuheben, da£ die MM A an dieser Schnittstelle ei- 
ne andere Message-ID tragen kann, wurde in diesem Ausfuh- 
rungsbeispiel als Wert BBBB. 3333@mms-relay02 . Siemens .de 
gewahlt (entspricht ID2 in Fig. 2). 

Bei Zustellung von MM B im PLZLL-Modus : 

3. Fall: M-Acknowledge . ind (MMS User Agent B — > MMS Relay 
B) : 

X-Mms -Message-Type : m- acknowledge- ind 
X-Mms -Transact ion- ID : 48 
X-Mms -Vers ion: 1 . 0 
X-Mms-Status : replace suc- 
cessful 



Erfolgte die Zustellung der MM B im PULL-Modus, schickt 
das MMS User Agent B vorzugsweise mit der WAP Nachricht 
M-Acknowl edge . ind eine Ruckmeldung zuruck an das MMS Re- 
lay B. Dazu wird das in dieser Erfindung erweiterte Hea- 
der-Feld X-Mms-Status benutzt. In diesem Ausf lihrungsbei- 
spiel konnte die MM A auf dem MMS User Agent B durch die 
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neue MM B ersetzt werden, was mit dem Feld-Wert „replace 
successful" ausgedruckt wird. Im MMS Relay B kann von der 
Transaktions-ID (Transaction-ID) (hier: 48) des WAP Nach- 
richten-Paares M-Retrieve. conf und M-Acknoledge . ind auf 
die Message- ID (hier: BBBB.3333@mms-relay02.siemens.de) 
der ersetzten MM A geschlossen werden. Dadurch ist das 
Verfassen einer Riickmeldung moglich, falls dies vom Ab- 
sender verlangt und vom Service Provider B unterstutzt 
wird. 

Bei Zustellung von MM B im PUSH-Modus 

3. Fall: M-NotifyResp.req (MMS User Agent B MMS Relay 
B) : 

X-Mms -Message - Type : m-noti fyresp-req 
X-Mms -Transact ion-ID: 38 
X-Mms - Versi on: 1.0 
X-Mms- Status : replace suc- 
cessful 



Erfolgte die Zustellung der MM B im PUSH-Modus, bestatigt 
das MMS User Agent B den korrekten Empfang von MM B vor- 
zugsweise mit der WAP Nachricht M-NotifyResp.reQ. Dazu 
wird bevorzugt das in dieser Erfindung erweiterte Header- 
Feld X-Mms-Status benutzt. In diesem Ausf uhrungsbeispiel 
konnte die MM A auf dem MMS User Agent B durch die neue 
MM B ersetzt werden, was mit dem Feld-Wert ^replace suc- 
cessful u ausgedruckt wird. Im MMS Relay B kann von der 
Transaction-ID (hier: 38) des WAP Nachrichten-Triples M- 
Notification. ind M-Retrieve . conf und M-NotifyResp.req auf 
die Message-ID (hier: BBBB . 333 3@mms-relay0 2 . Siemens . de) 
der ersetzten MM A geschlossen werden. Dadurch ist das 



200100797 



57 



Verfassen einer Ruckmeldung moglich, falls dies vom Ab- 
sender verlangt und vom Service Provider B unterstutzt 
wird. 

5 M-Delivery . ind (MMS Relay A — > MMS User Agent A) : 



10 



15 



20 



25 



X-Mms -Message-Type : m-del ivery- ind 

X-Mms-Message-ID: AAAA . 5555@mms-rela.y01 . Siemens . de 
X-Mms - Versi on: 1.0 
To: abcQsal . Siemens . de 

Date: Thu, 26 Oct 2000 13:12:11 +0100 



X-Mms-Status : replace suc- 
cessful 



Das MMS Relay A kann mit der WAP Nachricht M-Del ivery . ind 
eine Ruckmeldung zuriick an das MMS User Agent A schicken. 
In dem Feld Message-ID steht die ID des Anderungs- 
Auf trages. Fur den Status des Anderungs-Auf trages wird 
hier vorzugsweise ebenfalls das erweiterte Header-Feld X- 
Mms-Status benutzt, in dem das erfolgreiche Andern der 
MM A durch MM B mit dem Feld-Wert „ replace successful" bes- 
tatigt wird- Da dem MMS User Agent A der Zusammenhang 
zwischen der Message-ID des Anderungs-Auf trages und der 
Message-ID der MM A , die zuruckgeruf en werden sollte, be- 
kannt ist, kann dem Absender mitgeteilt werden, ob sein 
Anderungs-Auf t rag erfolgreich ausgefuhrt werden konnte 
oder nicht (sofern die beteiligten MMS Service Provider 
dies unterstutzen) . 



30 



Beispiel C: Alternative fur das Ubermitteln einer Status- 
Information 
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In den beiden zuvor beschriebenen Ausf uhrungsbeispielen 
wird eine Ruckmeldung uber den Ausgang eines erteilten 
Ruckruf- bzw. Anderungs-Auf trages vom MMS User Agent B 
zum MMS Relay B (bei Service Provider B) mit den WAP 
Nachrichten M-NotifyResp. ind (PUSH-Modus) oder M- 
Acknowledgement . ind ( PULL -Modus ) , bzw. vom MMS Relay A 
zum MMS User Agent A (bei Service Provider A) mit der WAP 
Nachricht M-Delivery. ind ubertragen. Dazu wurden neue 
Feld-Werte in das Header-Feld X-Mms-Status eingefiihrt. 
Dieses Vorgehen ist zwar effizient, jedoch nicht ganz 
konform zur bisherigen Nutzung des Header-Feldes X-Mms- 
Status. Deshalb wird im folgenden ein alternatives Aus- 
fuhrungsbeispiel fur das Ubermitteln einer Ruckmeldung 
beschrieben. Das Absenden sowie das Ausfuhren eines Ruck- 
ruf- oder Anderungs-Auf trages bleibt dabei wie in Bei- 
spiel A und Beispiel B beschrieben zweckmaSigerweise un- 
verandert . 

Mit dieser Alternative wird das Header-Feld X-Mms-Sta tus 
(so wie es im Encapsulation Standard (s.o.) ursprunglich 
vorgesehen ist) weiterhin ausschlieSlich dazu benutzt, 
den Absender liber den Zustand der zuletzt verschickten MM 
(also derjenigen, die den Ruckruf- oder Anderungs-Auf trag 
beinhaltete) zu informieren und nicht (wie unter Ausfuh- 
rungsbeispiel A und B beschrieben) liber den Ausgang eines 
Ruckruf- oder Anderungs-Auf trages . Fur diesen Fall wird 
deshalb ein weiteres Header-Feld definiert, mit dem der 
Absender uber den Ausgang seines Ruckruf- oder Anderungs- 
Auf trages in Kenntnis gesetzt werden kann. Es wird vorge- 
schlagen, dieses neue Header-Feld mit dem Namen X-Mns- 
Original-Message-Status zu versehen und ihm die hexadezi- 
male Codierung 0x86 (dezimal: 134) zu geben. Weiterhin 
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wird vorgeschlagen, z.B. als Feld-Werte <Octetl28> fur 
„Die MM wurde erfolgreich zuriickgeruf en" , <Octetl29> fur 
„Der Ruckruf der MM ist f ehlgeschlagen" , <Octetl30> fur 
„Die MM wurde erfolgreich geandert bzw. ersetzt" und 
<0ctetl31> fur „Das Andern bzw. Ersetzen der MM ist fehl- 
geschlagen" zu benutzen. Fig. 7 zeigt das in dieser Al- 
ternative vorgestellte Header-Feld. 

Beispiel D: Alternative fiir das Ubermitteln einer Riick- 
meldung 

In den Beispielen A und B wurde die MM A , auf die sich die 
Ruckmeldung bezieht, iiber das Ergebnis des Ruckruf- bzw. 
Anderungs-Au ft rages anhand der Message-ID von MM B und an- 
hand der Transaktion-IDs in den WAP Nachrichten M- 
NotifyResp. ind oder M- Acknowledge . ind identif iziert . 

Denkbar ist auch, die Nachrichten-ID derjenigen MM A/ die 
zuriickgeruf en oder geandert, insbesondere ersetzt, worden 
ist, direkt mit den WAP Nachrichten M-NotifyResp . ind oder 
M-Acknowledgement . ind (an Service Provider B) , bzw. M- 
Delivery. ind (von Service Provider A) zu ubertragen. Dazu 
wird vorgeschlagen, ein neues Header-Feld einzufuhren, 
welches beispielsweise die zweckmaSige Bezeichnung X-Mms- 
Original-Message-ID tragt, und ihm die hexadezimale Co- 
dierung 0x87 (dezimal: 13 5) zu geben. Die Feld-Werte die- 
ses neuen Header-Feldes beinhalten bevorzugt die Message- 
ID der Original-MM A und werden gemaS des Encapsulation- 
Standards (s.o.) als Text-String codiert. Fig. 8 zeigt 
das in dieser Alternative vorgestellte Header-Feld. 
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Anhang 

Tabelle 1: Moglichkeiten der Feld-Wert-Codierung nach WAP- 
203-WSP, Version 4-May-2000; Wireless Application Protocol, 
Wireless Session Protocol Specification; Chapter 8.4: "Header 
Encoding" . 



Erstes Oktet 
des Feld-Wertes 


Mogliche Kombinatio- 
nen 


Anzahl der 
nachfolgenden Okte- 
ten 


0. . .30 


31 


0. . .30 


31 


1 


> 30 


32 . . . 127 (fur Text) 


96 ! 


> 0 


128. . .255 


128 


0 
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Tabelle 2: WAP Nachricht M-Send.req (dick eingerahmt : neu 
nach dieser Erfindung) . 



Name 


Inhalt 


Kommentare 


X-Mms- 

Message-Type 


m-send-req 


Zwingend . 
Spezifiert den 
Transaktionstyp . 


X-Mms- 

Trans ac t ion— 
ID 


Ein eindeutiger 
Identif lzierer 


Zwingend . 

Diese Transaktions-ID 
identif iziert nur das M- 
Send.req und die 
korrespondierende Antwort . 


X-Mms-MMS- 
Version 


Versionsnummer 


Zwingend . 

Die MMS Versionsnummer. GemaS 
dieser Spezif ikation ist die 
Version 1.0. 


Date 


Abs endeda turn 


Optional . 

Ankunftszeit der Nachricht am 
MMS Server. Der MMS Server 
wird dieses Feld generieren 
wenn es nicht vom Terminal zur 
Verfugung gestellt wird. 


From 


Abs ender adr e s s e 


Zwingend. 

Dieses Feld MUSS in einer 
rjacnricnt vornanden sem, die 
an einen Empfanger 
ausgeliefert wird. Dieses Feld 
KANN vom Absenderklienten 
erzeugt werdnen oder KANN am 
MMS Server eingefiigt werden, 
indem „ insert-an-address- 
token" benutzt wird. 
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To 


Adresse #1 


Optional. 

Jede Anzahl- von Adressf eldern 
ist erlaubt . 


Cc 


Adresse #1 


Optional - 

Jede Anzahl von Adressf eldern 
ist erlaubt. 


Bcc 


Adresse #1 


Optional . 

Jede Anzahl von Adressf eldern 
ist erlaubt . 


Subject 


Betref f 


Optional . 


X-Mms- 

Message- 

Class 


Privat | 
Anzeige 1 
Information | 
Auto 


Optional . 

„Auto" bezeichnet eine 
Nachricht, die automatisch vom 
Klienten generiert wird. Wenn 
die Nachrichtenklasse „Auto" 
ist, SOLL der 

Ursprungsterminal NICHT einen 
Auslief erungsbericht oder 
Lesebericht anf ordern . 
Wenn des Feld nicht vorhanden 
ist, interpretiert der 
Empfanger die Nachricht als 
privat . 


X-Mms- 
Recall-ID 


ID 


Optional . 

Diese ID SOLL immer vorhanden 
sein, wenn ein Absender eine 
zuvor versendete MM 
zuriickruf en will . Bezeichnet 
die Nachrichten-ID der MM, die 
ein Absender zuriickruf en will. 


X-Mms- 
Replace-ID 


ID 


Optional . 

Diese ID SOLL immer vorhanden 
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sein, wenn em AJDsenaer eme 
zuvor versendete MM andern 
will. Bezeichnet die 
Nachrichten-ID der MM, die ein 
Absender andern will. 


X-Mms- 
Recfues t- 
Report 


Ja | Nein 


Optional. 

Bezeichnet, ob der Absender 
einen Bericht dartiber 
anfordert, ob ein Ruckruf- 
oder ein Anderungs-Auf trag 
erfolgreich ist oder nicht. 


X -Mms - Exp i r y 


Zeitdauer , 
wahrend der die 
Nachricht im 
Server 
gespeichert 
wird oder 
Zeitpunkt, zu 
dem die 
Nachricht 
geloscht wird. 


Optional. Voreinstellung: 
Maximum, das Feld hat zwei 
Formate, entweder absolut oder 
intervallbezogen . 


X-Mms- 
Delivery- 


Zeitpunkt der 
gewtinschten 
Aus 1 ief erung 


Optional . Voreinstellung : 
sofort. Bezeichnet die friihest 
mogliche Auslieferung der 
Nachricht an den Empf anger. 
Das Feld hat zwei Formate, 
entweder absolut oder 
intervallbezogen . 


X-Mms- 
Priority 


Niedrig | 
Normal | Hoch 


Optional . Voreinstellung : 
Normal 


X-Mms- 
Sender- 


Verbergen | 
Zeigen 


Optional . Voreinstellung : 
Zeige dem Empfanger 
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Visibility 




Adresse/Telef onnummer des 
Absenders , auEer der Absender 
hat eine geheime 
Nummer/Adresse . 
Verbergen = zeige keine 
Adresse. Zeige = zeige sogar 
gehe ime Adr e s s e . 


X-Mms- 
Deli very- 
Report 


Ja | Nein 


Optional. Voreinstellung wird 
bestimmt, wenn der Service 
angefordert wird. 
Spezif iziert, ob der Nutzer 
einen Auslief erungsbericht von 
jedem Empf anger mochte. Wenn 
Nachrichtenklasse w Auto" ist, 
SOLL das Feld immer vorhanden 
sein und der Wert SOLL „No" 
sein. 


X-Mms -Read- 
Reply 


Ja | Nein 


Optional. Spezif iziert , ob der 
Nutzer einen Lesebericht von 
jedem Empf anger in Form einer 
neuen Nachricht mochte. Wenn 
Nachrichtenklasse „Auto" ist, 
ou-uij aas reict immer vornanaen 
sein und der Wert SOLL „No" 
sein. 


Content-Type 


Inhaltstyp- 
Identif izierer 


Zwingend. Der Inhaltstyp der 
Nachricht . 
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Tabelle 3: WAP Nachricht M-Send. conf (dick eingerahmt : neu 
nach dieser Erfindung) . 



Name 


Inhalt 


Koramentare 


X-Mms- 

Mes sage -Type 


m-send-conf 


Zwingend. Identif iziert den 
Nachrichtentyp . 


a— ixLms — 

Transaction- 
ID 


Em 

eindeutiger 
Identif izierer 


Zwingend . Diese Transaktions— 
ID identif iziert nur das M- 
Send. conf und die 
korrespondierende Anforderung. 


X-Mms-MMS- 
Version 


Ver s i onsnununer 


Zwingend . 

Die MMS Versionsnummer. GemaE 
dieser Spezif ikation ist die 
version x . u . 


X-Mms- 

Supported- 

Feature 


Ruckruf | 
Andern | Keine 
Unters tut zung 


Optional . 

Dieses Feld SOLL immer 

vorhflndpn cp -j n nm an7n 7Pi rrpn 

v WLliaiiuCU OCXll ; VXLll Ull Li. c _L y Ci 1 / 

ob ein Service Provider fahig 
ist, ein oder mehrere der 
Dienstmerkmale zu 
unterstiit zen . 


X-Mms- 

Charging- 

Amount 


Charge 


Optional . 
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X-Mms- 

Response- 

Status 


Status Code 


Zwingend. MMS spezifischer 
Status . 


Message-ID 


ID 


Optional. Dies ist eine 
eindeutige, der Nachricht 
zugeordnete Ref erenz . Diese ID 
SOLL immer vorhanden sein, 
wenn der MMS Server die 
iMa^iii. J.L.X1U cuvzepLieru . 
Die ID ermoglicht einem 
Kunden, Auslief erungsberichte 
mit zuvor versendeten 
Nachricht abzugleichen . 
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Tabelle 4: WAP Nachricht M-Notification. ind (dick eingerahmt : 
neu nach dieser Erfindung) . 



Name 


Inhalt 


Kommentare 


X-Mms -Message- 
Type 


m-noti f ication- 
ind 


Zwingend. Spezifiziert den 
Trans aktionstyp . 


X-Mms - 

Transaction-ID 


Ein eindeutiger 
Identif izierer 


Zwingend. Identif iziert die 
Benachrichtigung und die 
nachfolgende Transaktion die 
durch die folgende M- 
NotifyResp abgeschlossen 
wird. 


X-Mms -MMS- 
Version 


Ve r s i on s numme r 


Zwingend . 

Die MMS Versionsnummer . GemaS 
dieser Spezif ikation ist die 
Version 1.0. 


From 


Abs ender adr e s s e 


Optional . 

Wenn das Verbergen der 
Adresse des Absenders vor dem 
Empfanger unterstutzt wird, 
wird der MMS Server dieses 
rciu iiiLiit emem 
Nachrichtenkopf hinzufugen. 


X-Mms- 

Recalled-URI 


URI 


Optional . 

Bezeichnet ein URI, das nicht 
mehr gultig ist. 


X-Mms - 

Replaced-URI 


URI 


Optional . 

Bezeichnet ein URI, das nicht 
mehr gultig ist. 


X-Mms-Date-Of- 
Execution 


Datum 


Optional . 

Bezeichnet das Datum, an dem 
ein Ruckruf- oder ein - 
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Anderungs-Auf trag ausgefuhrt 
wurde . 


X-Mms -Recal 1 - 
ID 


ID 


Optional . 

ID SOLL immer vorhanden sein, 
wenn ein Absender eine zuvor 
versendete MM zuruckrufen 
will, die schon an den User 
Agent ausgeliefert wurde. 
Bezeichnet die Nachrichten-ID 
der MM, die ein Absender 
zuruckrufen will. 


X-Mms -Replace- 
ID 


ID j 


Optional . « 
ID SOLL immer vorhanden sein, 
wenn ein Absender eine zuvor 
versendete MM andern will, 
die schon an den User* Aereani- 
(UA) ausgeliefert wurde. 
Bezeichnet die Nachrichten-ID 
der MM, die ein Absender 
andern will . 
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X-Mms -Message- 
Class 


Privat | 
Anzeige | 
Information | 
Auto 


Zwingend . 


X-Mms -Mes sage - 
Size 


Grofie der 
jNacnr i cn u 


Zwingend. Voile GroSe der 
iNacnricnt in UKtecen. 


X-Mms -Expiry 


Zeitdauer , 
wahrend der die 

Tyia Vj T" *i r"«Vi1~ 

zuganglich ist. 


Zwingend. Das Feld hat nur 
ein Format: intervallbezogen . 


X-Mms -Content- 
Location 


URI 


Zwingend. Dieses Feld 
identif iziert den Ort der 
Nachricht . 
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Tabelle 5: WAP Nachricht M-NotifyResp. req (dick eingerahmt 
neu nach dieser Erf indung) . 
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Name 


Inhalt 


Koxnxnent aire 


X-Mms- 

Message-Type 


m-send-conf 


Zwingend . 

Identif iziert den 

Nachrichtentyp . 


X-Mms- 

Tr ans ac t i on- 
ID 


Ein eindeutiger 
Identif izierer 


Zwingend. Diese 
Transaktions-ID 
identif iziert nur das 
M-Send. conf und die 
entsprechende 
Anforderung . 


X-Mms -MMS - 
Version 


Vers i onsniunmer 


Zwingend . 
Die MMS 

Vers i onsnummer . GemaS 
dieser Spezif ikation 
ist die Version 1.0. 


X-Mms-Status 


Zuriickgewiesen j 
Heruntergeladen | 
Verschoben | 
Ruckruf erfolgreich | 
Ruckruf f ehlgeschlagen | 
Andern erfolgreich | 
Andern f ehlgeschlagen | 
Ruckru f - Di ens tmer kmal 
unterstutzt | Andern- 
Dienstmerkmal 
unterstutzt 


Zwingend . 

Nachrichtenstatus . 


V _TvTm q -Ppnnrt* — 

Allowed 


U d/ 1>J J. 1 1 


Optional . 

Voreinstellung : Ja . 
Senden des 

Ablief erungsberichts 
dem Nutzer erlaubt. 
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Tabelle 6: WAP Nachricht M-Retrieve. conf (dick eingerahmt: 
neu nach dieser Erfindung) . _ 



Name 


Xnhalt 


Kommentare 


X-Mms- 

Message-Type 


m-retrieve-conf 


Zwingend . j 
Spezifiziert den 

Nachrichtentyp. [ 


X-Mms- 

Transac t i on- 
ID 


Ein eindeutiger 
Identif izierer 


Optional. Identif ziert | 
entweder die Transaktion, die j 
durch M-Notification ohne M- 
NotifResp gestartet wurde, 
oder eine neue Transaktion, ' 
wenn eine auf geschobene 
Auslieferung erwunscht wurde. 
Die neue Transaktions-ID ist j 
optional. 


Message-ID 


ID 


Optional. Dies ist eine 
eindeutige, einer Nachricht j 
zugeordnete Ref erenz . Diese ID 
SOLL immer vorhanden sein, ' 
wenn der Auftraggeber eine 
Gelesen-Antwort anforderte. 
Die ID ermoglichet einem * 
Kunden gelesene Berichte mit 
zuvor versendeten Nachrichten 
abzugleichen. 


X-Mms-MMS- 
Version 


Versionsnummer 


Zwingend. Die MMS 

Versionsnummer. GemaS dieser 1 
Spezif ikation ist die Version 
1.0. 


Date 


Sendedatum 


Zwingend. 
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From 


Absenderadresse 


Optional . 

Wenn das Verbergen der 
Senderadresse vor dem 
Empfanger unterstlitzt wird, 
wird der MMS Server dieses 
reia nicnL zu einem 
Nachrichtenkopf hinzufiigen. 


To 


Adresse #1 


Optional . 

J"ede Anzahl von Adressf eldern 

J- O L» Ci luUJJt • 


Cc 


Adresse #1 


Optional . 

Jede Anzahl von Adressf eldern 
ist erlaubt. 


Subject 


Betref f 


Optional . 


X-Mms- 
Replace-ID 


ID 


Optional . 

Die ID SOLL immer vorhanden 
sein, wenn ein Absender eine 
zuvor versendete MM andern 
will. Bezeichnet die 
iNacnr icnuen— ± u aer jyuxL, aie aer 
Absender andern will. 


X-Mms-Status 


Andern 

erf olgreich 


Optional 

Zeigt an, ob eine Nachricht 
t:i bcLzt wurae . 


X-Mms-Date- 
Of-Execution 


Datum 


Optional . 

Zeigt das Datum an, an dem ein 
Ruckruf oder eine Anderung 
auscrefiihrt wurde 


X-Mms- 

Message- 

Class 


Privat | 
Anzeige j 
Information | 
Auto 


Optional . 

Wenn das Feld nicht vorhanden 
ist, interpretiert der 
Empfanger die Nachricht als 
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privat . 


-X-Mms- 
Priority 


NiedrigJ Normal 
| Hoch 


Optional . Voreinstellung : 
Normal 


X-Mms- 

T)f* ~| "j \rprv- 

Report 


Ja | Nein 


Optional . Voreinstellung : 
Nein. Spezif iziert , ob der 
Nutzer einen 

Auslief erungsbericht von jedem 
Empfanger in Form einer neuen 
Nachricht wunscht . 


Y — Mm c-RoaH- 

Reply 


Ja | Nem 


Optional . Voreinstellung: 
Nein. Spezif iziert , ob der 
Nutzer einen Lesebpri phi- vnn 
jedem Empfanger in Form einer 
neuen Nachricht wunscht. 


Content -Type 


Inhaltstyp- 
Identif izierer 


Zwingend. Der Inhaltstyp der 
Nachricht . 
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Tabelle 7: WAP Nachricht M- Ac kn owl edge. ind (dick eingerahmt 
neu nach dieser Erfindung) . 
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Name 


Inhalt 


Kommentare 


X-Mms - 

Message-Type 


m- acknowledge - 
ind 


Zwingend. Identif iziert den 
Transaktionstyp . 


X-Mms- 

Transact ion- 
ID 


Ein 

eindeutiger 
Identif izierer 


Optional. Dies ist die 
Transaktionsnuiruner , die von 
der unmittelbar vorherigen M- 
Retrieve Operation stammt. j 
Wenn die M-Retrieve Operation 
keine Transaktionsnuiruner 
enthielt, wird die 
Transaktionsnuiruner vom M- 
Acknowledge ebenso 
fortgelassen. 


X-Mms -MMS- 
Version 


Ver s i onsnummer 


Zwingend. 

Die MMS Versionnummer . GemaS 
dieser Specification ist die 
Version 1.0. 


X-Mms- Status 


Riickruf 

erf olgreich | 

Riickruf 

erfolglos | 

Andern 

erfolgreich | 
Andern 

erfolglos , 


Optional . 

i 


X-Mms -Report- 
Allowed 


Ja/Nein 


Optional. Voreinstellung : Ja. 
Senden von 

Auslief erungsbericht an den 
Nutzer erlaubt. 
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Tabelle 8: WAP Nachricht M-Delivery. ind (dick eingerahmt : neu 
nach dieser Erfindung) . 



Name 


Inhalt 


Kommentare 


X-Mms- 

Message-Type 


m-delivery-ind 


Zwingend. Identif iziert den 
PDU-Typ 


Y — Mm c — 

Message-ID 




ZiWiny ena . von oencz reqruest; 
verbindet den 

Auslief erungsbericht mit der 
gesendeten Nachricht in MS. 


Y _ Mm q _ MM Q _ 

Version 


vci o xoiioiiuJiuTiezr 


tiWinyeriQ . 

Die MMS Versionsnummer . GemaS 
dieser Spezif ikation ist dies 
die Version 1.0. 


To 


Empf angeradresse 


Zwingend. Wird gebraucht zum 
Berichten im Falle einer 
„point- to-multipoint" 
Nachricht . 


Date 


Ereignisdatum 


Zwingend. Zeitpunkt, zu dem 
die Nachricht vom Empf anger 
oder dem MMS -Server 
bear be i t e t ( abgeho 1 1 , 
abcrelauf en ) wurdp 


X-Mms-Status 


Ruckruf 
erfolgreich | 
Ruckruf 
erfolglos | 
Andern 

erfolgreich | 
Andern erfolglos 


Zwingend. Status der 
Nachricht . 
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Patentanspruche 

1. Verfahren zum Zugreifen auf eine erste Nachricht (MM A ) , 
insbesondere eine multimediale Nachricht (Multimedia Message, 
MM) vorzugsweise vom MMS-Typ, wobei die erste Nachricht (MM A ) 
mittels einer Sendeapplikation (MMS User Agent A) einer Sen- 
deeinheit an eine Empf angsapplikation (MMS User Agent B) ei- 
ner Empfangseinheit gesendet wird, dadurch gekennzeich- 
net, daS eine zweite Nachricht (MM B ) mit einem Manipulati- 
onsauftrag zur Manipulation der ersten Nachricht (MM A ) er- 
stellt, versendet, empfangen, weitergeleitet und/oder verar- 
beitet wird, urn einen manipulierenden Zugriff auf die erste 
Nachricht (MM A ) zu veranlassen oder zu vermitteln. 

2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, daS 
die erste Nachricht (MM A ) und die zweite Nachricht (MM B ) uber 
Funk, uber Mobilf unksyst erne , zwischen Mobilf unksystemen, ins- 
besondere Inter-Operator- IP-backbone, zwischen Mobilf unknet- 
zen und anderen Nachrichten-Netzen, insbesondere Internet- 
Email, und/oder uber das Internet versendet werden. 

3. Verfahren nach Anspruch 1 oder Anspruch 2, dadurch ge- 
kennzeichnet, daS die erste Nachricht (MM A ) und die zweite 
Nachricht (MM B ) uber mindestens ein senderseitiges Netzwerk- 
element (MMS Relay A) eines Service Providers (Service Provi- 
der A) und. mindestens ein empf angerseitiges Netzwerkelement 
(MMS Relay A; MMS Relay B) eines Service Providers (Service 
Provider A; Service Provider B) an die Empf angsapplikation 
(MMS User Agent B) gesendet wird. 

4. Verfahren nach Anspruch 3, dadurch gekennzeichnet, dag 
das mindestens eine senderseitige Netzwerkelement (MMS Relay 
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A) und das mindestens eine empf angerseitige Netzwerkelement 
(MMS Relay B) dem Zustandigkeitsbereich (MMSE A ) eines einzi- 
gen Service Providers (Service Provider A) angehoren oder so- 
gar identisch sind. 

5. Verfahren nach einem der vorhergehenden Anspruche, da- 
durch gekennzeichnet, dafi die Sendeapplikation (MMS User A- 
gent A) und die Empf angsapplikation (MMS User Agent B) iden- 
tisch sind. 

6. Verfahren nach einem der vorhergehenden Anspruche, da- 
durch gekennzeichnet, daS der manipulierende Zugriff auf die 
erste Nachricht (MM A ) auf einem sendersei tigen Netzwerkele- 
ment (MMS Relay A) , auf einem empf angerseitigen Netzwerkele- 
ment (MMS Relay B) und/oder auf der Empf angsapplikation (MMS 
User Agent B) erfolgt. 

7. Verfahren nach einem der vorhergehenden Anspruche, da- 
durch gekennzeichnet, daS der Manipulationsauf trag den Riick- 
ruf bzw. das Loschen der ersten Nachricht (MM A ) umf aSt . 

8. Verfahren nach einem der Anspruche 1 bis 6, dadurch ge- 
kennzeichnet, daS der Manipulationsauf trag das Andern der 
ersten Nachricht (MM A ) umfafit, vorzugsweise durch Ersetzen 
der ersten Nachricht (MM A ) durch die zweite Nachricht (MM B ) . 

9. Verfahren nach Anspruch 8, dadurch gekennzeichnet, daS 
die zweite Nachricht (MM B ) im Falle eines Anderungs - Auf t rages 
entweder im PUSH-Modus (Druck-/Bring-Modus) oder im PULL- 
Modus (Zieh-/Hol-Modus) heruntergeladen wird. 

10. Verfahren nach einem der vorhergehenden Anspruche, da- 
durch gekennzeichnet, da£ die zweite Nachricht (MM B ) mit dem 
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Manipulationsauf trag an den Empf anger der ersten Nachricht 
(MM A ) verschickt wird, wobei zur Kennung bzw-. Identif izierung 
der ersten Nachricht (MM A ) vorzugsweise deren Identif ikati- 
onsnununer (ID1) verwendet wird, welche die erste Nachricht 
5 (MM A ) zwischen der Sendeapplikation (MMS User Agent A) und 
einem senderseitigen Netzwerkelement (MMS Relay A) eindeutig 
kennzeichnet . 

11. Verfahren nach einem der vorhergehenden Anspruche, da- 

10 durch gekennzeichnet , daS beim Versenden einer Nachricht ei- 
nem senderseitigen Netzwerkelement (MMS Relay A) von der Sen- 
deapplikation (MMS User Agent A) eine Oder mehrere der fol- 
genden Inf ormationen bereitgestellt werden: 

- Kennzeichnung, daS es sich bei der Nachricht (MM B ) urn einen 
15 Manipulationsauf trag handelt; 

- Identif ikationsnummer der ersten Nachricht (MM A ) , die mani- 
puliert werden soil; 

- Information, daS der Absender eine Ruckmeldung iiber den 
Ausgang der von ihm initiierten Manipulation anf ordert . 

20 

12. Verfahren nach einem der vorhergehenden Anspruche, da- 
durch gekennzeichnet, daS der Sendeapplikation (MMS User A- 
gent A) von einem senderseitigen Netzwerkelement (MMS Relay 
A) die Information bereitgestellt wird, ob dieses Netzwerk- 

25 element (MMS Relay A) die Manipulation gemaS den vorhergehen- 
den Anspruchen unterstiitzt und/oder ob der Manipulations - 
Auftrag der Sendeapplikation (MMS User Agent A) von dem Ser- 
vice Provider (Service Provider A) der Sendeapplikation (MMS 
User Agent A) angenommen wurde . 

30 

13. Verfahren nach einem der vorhergehenden Anspruche, da- 
durch gekennzeichnet, daS bei Zugehorigkeit der Sendeapplika- 
tion (MMS User Agent A) und der Empf angsapplikat ion (MMS User 
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Agent B) zu unterschiedlichen Zustandigkeitsbereichen (MMSE A , 
MMSE B ) von Service Providern (Service Provider A, Service 
Provider B) einem empf anger seitigen Netzwerkelement (MMS Re- 
lay B) von einem senderseitigen Netzwerkelement (MMS Relay A) 
eine oder mehrere der folgenden Inf ormationen bereitgestellt 
werden : 

- Kennzeichnung, daS es sich bei der zweiten Nachricht (MM B ) 
um einen Manipulationsauf trag handelt; 

- Identif ikationsnummer der ersten Nachricht (MM A ) / die mani- 
puliert werden soli ; 

- Information, daS der Absender eine Ruckmeldung uber den 
Ausgang der von ihm initiierten Manipulation anf ordert . 

14, Verfahren nach einem der vorhergehenden Anspriichen, da- 
durch gekennzeichnet , date Netzwerkelemente (MMS Relay A, MMS 
Relay B) von verschiedenen Service Providern (Service Provi- 
der A, Service Provider B) eine eineindeutige , umkehrbare Um- 
wandlung von auf die erste und/oder die zweite Nachricht be- 
zogene Identif ikationsnummern (ID1, ID3 ; ID4, ID6, ID5) vor- 
nehmen und die entsprechenden Inf ormationen vorzugsweise ver- 
walten. 

15. Verfahren nach einem der vorhergehenden Ansprtiche, da- 
durch gekennzeichnet, da£ im Falle eines Manipulationsauf - 
trags , insbesondere einschlieSlich eines Loschungsbef ehls , 
bei noch nicht erfolgter Benachrichtigung der Empf angsappli- 
kation (MMS User Agent B) uber die erste Nachricht (MM A ) die- 
se erste Nachricht (MM A ) im Zustandigkeitsbereich (MMSE A ) des 
senderseitigen Service Providers (Service Provider A) oder im 
Zustandigkeitsbereich (MMSE B ) des empf angerseitigen Service 
Providers (Service Provider B) manipuliert, insbesondere ge- 
loscht, wird, wobei bevorzugt die Empf.angsapplikation (MMS 
User Agent B) uber die Manipulation nicht informiert wird. 
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16. Verfahren nach einem der Anspruche 1 bis 14, dadurch ge- 
kennzeichnet , daS im Falle eines Manipulationsauf trags bei 
auf der Empf angsseite erfolgter Benachrichtigung, aber noch 
nicht heruntergeladener erster Nachricht (MM A ) diese erste 
Nachricht (MM A ) im Zustandigkeitsbereich (MMSE B ) des emp- 
fangsseitigen Service Providers (Service Provider B) manipu- 
liert wird, wobei die Empf angsapplikation (MMS User Agent B) 
liber die Manipulation und iiber deren Zeitpunkt vorzugsweise 
informiert wird. 

17. Verfahren nach einem der Anspruche 1 bis 14, dadurch ge- 
kennzeichnet, dafi im Falle eines Manipulationsauf trags bei 
auf der Empf angsseite erfolgter Benachrichtigung, aber noch 
nicht heruntergeladener erster Nachricht (MM A ) diese erste 
Nachricht (MM A ) im Zustandigkeitsbereich (MMSE A ) des sender- 
seitigen Service Providers (Service Provider A) manipuliert 
wird, wobei die Empf angsapplikation (MMS User Agent B) iiber 
die Manipulation vorzugsweise nicht informiert wird. 

18. Verfahren nach einem der vorhergehenden Anspruche, da- 
durch gekennzeichnet , dafi der Empf angsapplikation (MMS User 
Agent B) von einem empf angerseitigen Netzwerkelement (MMS Re- 
lay B) eine oder ggf . mehrere der folgenden Inf ormationen, 
vorzugsweise in einer Benachrichtigung, bereitgestellt wer- 
den: 

- Information, daS eine lediglich angekundigte , aber noch 
nicht ausgelieferte erste Nachricht (MM A ) nicht mehr zum Her- 
unterladen bereitliegt, oder durch eine neue Nachricht (MM B ) 
geandert worden ist, wobei die Identif izierung der ersten 
und/oder der zweiten Nachricht (MM A , MM B ) vorzugsweise anhand 
des URI (Uniform Resource Identifier, d.h. einem Speicher- 
platz) erfolgt; 
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- Information, daS eine schon ausgelief erte erste Nachricht 
(MM A ) vom Absender manipuliert werden mochte, wobei die Iden- 
tifizierung der ersten Nachricht (MM A ) auf der Empf angsappli- 
kation (MMS User Agent B) vorzugsweise anhand einer Nachrich- 
tenreferenz erfolgt, welche vorzugsweise ein URI ist, unter 
desssen Speicherplatz eine Standard-Text-Nachricht des emp- 

f angerseitigen Service Providers (Service Provider B) abge- 
speichert ist, wobei die URI bevorzugt aus der Identif ikati- 
onsnummer (ID1) der ersten Nachricht (MM A ) oder von einem 
empf angerseitigen Netzwerkelement (MMS Relay B) festgelegten 
zweiten Identif ikationsnummer (ID2) zusammengesetzt ist; 

- Kennzeichnung, daS die zweite Nachricht (MM B ) einen Manipu- 
lationsauf trag enthalt, der auf der Empf angsapplikation (MMS 
User Agent B) ausgefiihrt werden soil; 

- Information, welche bereits ausgelief erte Nachricht (MM A ) 
manipuliert werden soli; 

- Information, wann die Manipulation ausgefiihrt wurde; 

- Information, da£ die ausgelief erte zweite Nachricht (MM B ) 
eine nachtraglich geanderte Nachricht ist; 

- Information, welcher Art die vorzunehmende Manipulation 
ist . 

19. Verfahren nach einem der vorhergehenden Anspruche, da- 
durch gekennzeichnet , daS einem empf angerseitigen Netzwerk- 
element (MMS Relay B) von der Empf angsapplikation (MMS User 
Agent B) nach ihrer Benachrichtigung uber die zweite Nach- 
richt (MM B ) mindestens eine der folgenden Informationen be- 
reitgestellt werden: 

- Information, ob die Empf angsapplikation (MMS User Agent B) 
verstanden hat, daS die zuvor lediglich angekundigte erste 
Nachricht (MM A ) erfolgreich manipuliert wurde; 
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- Information, ob die Manipulation der bereits heruntergela- 
denen ersten Nachricht (MM A ) erfolgreich ausgefuhrt werden 
konnte; 

- Information, ob der Empf anger dariiber informiert wurde 
und/oder zugestimmt hat, dafi die bereits heruntergeladene 
Nachricht (MM A ) manipuliert wurde; 

- Information, ob im Falle eines Anderungs-Auf trags die Ande- 
rung der bereits heruntergeladenen ersten Nachricht (MM A ) au- 
tomatisch (PUSH-Modus) oder auf Veranlassung des Empf angers 
(PULL-Modus) durchgefuhrt wurde; 

- Information, welcher Art die vorzunehmende Manipulation 
ist . 

20. Verfahren nach einem der vorhergehenden Anspruche, da- 
durch gekennzeichnet , da£ bei Zugehorigkei t der Sendeapplika- 
tion (MMS User Agent A) und der Empf angsapplikation (MMS User 
Agent B) zu unterschiedlichen Zustandigkeitsbereichen (MMSE A , 
MMSE B ) von Service Providern (Service Provider A, Service 
Provider B) einem senderseitigen Netzwerkelement (MMS Relay 
A) von einem empf angerseitigen Netzwerkelement (MMS Relay B) 
eine oder mehrere der folgenden Inf ormationen bereitgestellt 
werden : 

- Information, ob der Manipulationsauf trag erfolgreich ausge- 
fiihrt werden konnte; 

- Information, wann der Manipulationsauf trag ausgefuhrt wur- 
de ; 

- Information, ob der Manipulationsauf trag automatisch ausge- 
fuhrt wurde; 

-Information, ob der Empfanger iiber die Manipulation infor- 
miert wurde und/oder der Manipulation zugestimmt hat und/oder 
die Manipulation vom Empfanger veranlaSt wurde; 
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- Information, daS die bereits heruntergeladene erste Nach- 
richt (MM A ) manipuliert wurde, oder die erste Nachricht (MM A ) 
vor einer Anderung noch nicht heruntergeladen war; 

- Interims -Ident if ikationsnummer (ID3) der Nachricht (MM A ) , 
die manipuliert wurde; 

- Information, welcher Art die vorgenommene Manipulation ist. 

21. Verfahren nach einem der vorhergehenden Anspriiche, da- 
durch gekennzeichnet , dafi der Sendeapplikation (MMS User A- 
gent A) von einem senderseitigen Netzwerkelement (MMS Relay 
A) eine oder mehrere der folgenden Informationen bereitge- 
stellt werden: 

- Information, ob der Manipulationsauf trag erfolgreich ausge- 
fuhrt wurde; 

- Information, wann der Manipulationsauf trag ausgefuhrt wur- 
de; 

- Information, ob der Manipulationsauf trag automat isch durch- 
gef iihrt wurde ; 

- Information, ob der Empf anger iiber die Manipulation infor- 
miert wurde und/oder oder der Manipulation zugestimmt hat 
und/oder der Empf anger diese initiiert hat; 

- Information, daS die bereits heruntergeladene Nachricht 
(MM A ) manipuliert wurde, oder die erste Nachricht (MM A ) vor 
einer Anderung noch nicht ausgeliefert war; 

- Identif ikationsnummer (ID1) der Nachricht (MM A ) , die mani- 
puliert wurde. 

22. Verfahren nach einem der vorhergehenden Anspriiche, da- 
durch gekennzeichnet, daS das Versenden, Empfangen und Mani- 
pulieren der Nachrichten (MM) mittels WAP-Nachrichten (Wire- 
less Application Protocol) erfolgt. 
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23. Verfahren nach einem der vorhergehenden Anspriiche, da- 
durch gekennzeichnet, daS die Manipulationsauf trage durch Mo- 
difizieren von vorhandenen Kopffeldern (Header-Feldern) 
und/oder durch Hinzufugen von zusatzlichen Kopffeldern in ge- 
eigneten WAP-Nachrichten (WAP messages) , insbesondere solche 
nach dem WAP-MMSEncapsulation Standard und insbesondere die 
WAP-Nachrichten M-Send.req, M-Send.conf, M-Notif ication . ind, 
M-NotifyResp . req , M-Retr ieve . conf , M-Acknowledge . ind , M- 
Delivery . ind, implementiert werden . 

24. Verfahren nach einem der vorhergehenden Anspriiche, da- 
durch gekennzeichnet , daS die erste Nachricht (MM A ) fiir eine 
Ruckmeldung uber das Ergebnis des Manipulationsauf trags an- 
hand der Identif ikationsnummer (ID4) der zweiten Nachricht 

(MM B ) sowie der Transaktions-ldentif ikationsnummern der ent- 
sprechenden WAP-Nachrichten, oder anhand eines zusatzlichen 
Kopffeldes (Header-Feldes ) , wobei Feld-Werte des neuen Kopf- 
feldes die Identif ikationsnummer (ID1) der ersten Nachricht 

(MM A ) enthalten, identif iziert wird. 

25. Sende- und/oder Empf angseinheit , insbesondere zur zumin- 
dest teilweisen Durchfuhrung des Verfahrens nach einem der 
vorhergehenden Anspriiche, mit Mitteln zum Erstellen, Versen- 
den, Empfangen und/oder Verarbeiten einer ersten Nachricht 
(MM A ) , insbesondere einer multimedialen Nachricht (Multimedia 
Message) vorzugsweise vom MMS-Typ, gekennzeichnet durch 
Mittel zum Erstellen, Versenden, Empfangen und/oder Verarbei- 
ten einer zweiten Nachricht (MM B ) , wobei die zweite Nachricht 
(MM B ) einen Manipulationsauf trag zum Manipulieren der zuvor 
gesendeten ersten Nachricht (MM A ) umf aSt . 
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26. Sende- und/oder Empf angseinheit nach Anspruch 25, gekenn- 
zeichnet durch Mittel zum Ausfuhren des Manipulationsauf - 
trags . 

27. Sende- und/oder Empf angseinheit nach Anspruch 25 oder 26, 
dadurch gekennzeichnet , daS die Mittel zum Erstellen, Versen- 
den, Empfangen und/oder Verarbeiten der zweiten Nachricht 
(MM B ) WAP-Nachrichten, insbesondere solche nach dem WAP- 
MMSEncapsulation Standard und insbesondere die WAP- 
Nachrichten M-Send.req, M-Send.conf, M-Notif ication . ind, M- 
NotifyResp.req, M-Retrieve . conf , M-Acknowledge . ind und M- 
Delivery.ind mit entsprechend den im Rahmen der Manipulati- 
onsauftrage auszutauschenden Inf ormationen modif izierten 
Kopffeldern (Header-Feldern) und/oder zusatzlichen Kopffel- 
dern umfassen. 

28. Kommuni ka t i ons sy s t em , insbesondere Funkkommunikationssys- 
tem, insbesondere zur zumindest teilweisen Durchfuhrung des 
Verfahrens nach einem der Anspruche 1 bis 24, mit mit Sende- 
und/oder Empf angseinhei ten, insbesondere solchen nach einem 
der Anspruche 25 bis 27, kommunizierf ahigen Netzwerkelementen 
(MMS Relay A; MMS Relay B) , welche Mittel zum Empfangen und 
Weiterleiten von Nachrichten, insbesondere multimedialen 
Nachrichten (Multimedia Messages) vorzugsweise vom MMS-Typ, 
umfassen, dadurch gekennzeichnet, daS mindestens eines 
der Netzwerkelemente (MMS Relay A; MMS Relay B) Mittel zum 
Empfangen, Verarbeiten und/oder Weiterleiten einer zweiten 
Nachricht (MM B ) mit einem Manipulationsauf trag umfaSt, wel- 
cher sich auf eine empfangene und ggf . schon weitergeleitete 
erste Nachricht (MM A ) bezieht, urn einen manipulierenden 
Zugriff auf die erste Nachricht (MM A ) zu veranlassen oder zu 
vermitteln. 
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29. Kommunikationssystem nach Anspruch 28, gekennzeichnet 
. _ durch Mi.tt.el zum Ausfiihren des Manipulationsauf trags . 

30. Kommunikationssystem nach Anspruch 29, dadurch gekenn- 
5 zeichnet, daS die erste Nachricht (MM A ) auf einem Netzwerk- 

element (MMS Relay A; MMS Relay B) und/oder auf einer 

Empf angsaplikation (MMS User Agent B) einer Empf angseinheit 

manipulierbar ist, insbesondere loschbar und/oder anderbar. 

10 31. Kommunikationssystem nach einem der Anspruche 28 bis 30, 
dadurch gekennzeichnet, daS die Mittel zum Empfangen, Verar- 
beiten und/oder Weiterleiten der zweiten Nachricht (MM B ) WAP- 
Nachrichten, insbesondere solche nach dem WAP- 
MMSEncapsulation Standard und insbesondere die WAP- 

15 Nachrichten M-Send.req, M-Send.conf, M-Notif ication. ind, M- 
NotifyResp . req, M-Retrieve . conf , M-Acknowledge . ind und M- 
Delivery.ind mit entsprechend den im Rahmen der Manipulati- 
onsauftrage auszutauschenden Inf ormationen modif izierten 
Kopffeldern (Header-Feldern) und/oder zusatzlichen Kopffel- 

20 dern umfassen. 
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Zusammenf assung 

Verfahren und Vorrichtungen zum Zugreifen auf Nachrichten 

Es wird ein Verfahren vorgestellt, das es ermoglicht, eine 
vorzugsweise ttber ein Mobilfunksystem und/oder das Internet 
versendete erste Nachrichten, insbesondere einer multimedia- 
len Nachricht vorzugsweise vom MMS-Typ, mittels einer nach 
der ersten Nachricht versendeten zweiten Nachricht zu manipu- 
lieren, beispielsweise zuruckzuruf en oder zu andern. Gleich- 
falls wird eine Sende- und/oder Empf angseinheit mit Mitteln 
zum Erstellen, Versenden, Empfangen und/oder Verarbeiten ei- 
ner ersten Nachricht offenbart, welche Mittel zum Erstellen, 
Versenden, Empfangen und/oder Verarbeiten einer zweiten Nach- 
richt mit einem Manipulationsauf trag zum Manipulieren der zu- 
vor gesendeten ersten Nachricht umf afit . Zudem wird ein Kommu- 
nikationssystem mit mindestens einem Netzwerkelement be- 
schrieben, welches Mittel zum Empfangen, Verarbeiten und/oder 
Weiterleiten einer zweiten Nachricht mit einem Manipulations- 
auf trag umfaSt, welcher sich auf eine empfangene und ggf . 
schon weitergeleitete erste Nachricht bezieht, urn einen mani- 
pulierenden Zugriff auf die erste Nachricht zu veranlassen 
oder zu vermitteln. 



200100797 



1/4 



PULL 



MMS- 




UMTS 


Server 




Terminal 




Benachrichtigung 






^ Anforderung der MM 
















Ubertragung der MM 






Empfangsbestatigung 






PUSH 



MMS- 




UMTS 


Server 




Terminal 




Ubertragung der MM 
















Empfangsbestatigung 





Fig. 1 



MMS User 
Agent A 



MMS 
Relay 



MMS User 
Agent B 



MMa 
ID1 



User Agent A 
schickt MMa an 
User Agent B 



ID 1 



-M-Sencf.req- 
-M-Send.conf- 



-M-DeKvery.ind 



— M-Not/f/cat/on.ind^ 

VVSP GET 

M-netrieve.cqnf- 
M . A cknowledge.ind- 



MMA ID 2 



Fig. 2 



200100797 

2/4 




21 



Fig. 3 



MMS User 
Agent A 



MMS 
Relay A 



MMS 
Relay B 



MMS User 
Agent B 



Versand der 

Original 
Multimedia 
Nachrich MMA 



Versand des 
Manipulations- 
auftrages MMB 



Empfang der 
Ruckmeldung 
des ManipuL- 
auftrages 



- Abschicken 
v on MMa (iDif 



i 

/ 



■ Weiterleiten 



^bsch/cken 
-von MMs (f04i- 
Referenz IDi 



/ 



Statusmeldung. 
" MMB0D4) 



Weiter/e/ten 
von MMb (/d 6 ). 
Hoferenz: ID3 



Statusmeldung. 



u °erMMA(UR/^- 

— Aus/ieferung 
v onMMA(/D2j~ 



Benachr/ch(/g Uno 
He ferenz:iD2 
Auslieferuna 
Referenz: ID2 



AusUeferungs- 

" best&tigung 



* Umwandlung der Message IDs 
zwischen den Schnittstellen 



200100797 



3/4 



X-Mms -Rocall -ID: (0x7F) 

Recall-ID-Value = Text-String 

X-Mms -Recalled-URIz (0x80 ) 

Recalled-URI -Value = Text-String 



X-Mms -Replace -IDi (0x81) 

Replace-ID-Value = Text-String 

X-Mms -Replaced-URIt ( 0x82 ) 

Replaced-URI-Value = Text-String 

X-Mms - Support ed- Feature: ( 0x83 ) 

Supported-Feature-Value=Recall j Replace [ no support 

(Ruckruf / Andern / keine Unterstutzung) 
recall = <Octet 128> 
replace = <Octet 129> 
no support = <0ctet 13 0> 



X-Mms -Da te- Of -Execu t i on : ( 0x8 4 ) 

Date-Of-Execution-Value = Long-integer 
In seconds from 1970-01-01, 00:00:00 GMT 
(In Sekunden von 1970-01-01, 00:00:00 GMT) ) 



X-Mms -Request -Report : ( 0x85 ) 

Request-Report-Value = Yes | No (Ja / Nein) 
Yes = <Octet 128> 
No = <Octet 129> 



Fig. 5 
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X-Mms- Status* ( 0x14 ) 

Status-Value = Expired | (Abgelaufen) 

Retrieved | (Heruntergeladen) 
Rejected | (Zuruckgewiesen) 
Deferred j (Verschoben) 

Recall successful | (Ruckruf erfolgreich) 
Recall failed | (Ruckruf f ehlgeschlagen) 
Replace successful (Andern erfolgreich) 
Replace failed | ( Andern f ehlgeschlagen) 
Recall feature supported ) 

( Ruckruf -Merkmal unterstutzt) 
Replace feature supported 

(Anderungs -Merkmal -Unterstutzung) 

Expired = <Octet 128> 

Retrieved = <Octet 129> 

Rejected = <Octet 130> 

Deferred = <Octet 131> 

Recall successful = <Octet 132> 

Recall failed = <Octet 133> 

Replace successful = <Octet 134> 

Replace failed = <0ctet 135> 

Recall feature supported = <Octet 13 6> 

Replace feature supported = <Octetl37> 

Fig. 6 



X-Mms -Original -Message-Status : ( 0x86 ) 

Original-Message-Status-Value = 

Recall successful | (Ruckruf erfolgreich) 
Recall failed | (Ruckruf f ehlgeschlagen) 
Replace successful | (Andern erfolgreich) 
Replace failed) (Andern f ehlgeschlagen) 

Recall successful = <Octet 128> 

Recall failed = <Octet 129> 

Replace successful = <0ctet 130> 

Replace failed = <Octet 131> 

Fig. 7 



X-Mms -Original -Message-ID: ( 0x87 ) 

Original-Message-ID-Value = Text-String 

Fig. 8 
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